lilJ/self-host-101
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

wow

Browse Source
This commit is contained in:
Kulvir Singh
2025-11-03 02:05:22 +05:30
parent 89a0026db8
commit 6694fabb14
2 changed files with 65 additions and 70 deletions
Download Patch File Download Diff File Expand all files Collapse all files

93
caddy/readme.md
View File

@@ -3,31 +3,27 @@
**Caddy** is a web server that:
* Serves websites and web applications
* Can act as a [reverse proxy](https://en.wikipedia.org/wiki/Reverse_proxy)
* Automatically gets and renews TLS certificates so you get HTTPS for free!!
## Installation
Follow the official [Caddy Installation guide](https://caddyserver.com/docs/install#debian-ubuntu-raspbian) to install it.
To check if Caddy is installed and running
To check if Caddy is installed and running
```bash
sudo service caddy status
# You should see something like
# active (running)
# active (running)
```
Caddy is now running! By default, it listens on port 80 (HTTP). Visit your domain name in a browser - you should see Caddy's default welcome page.
Caddy's main config file is usually at `/etc/caddy/Caddyfile`.
This is where we will configure caddy web server.
Caddy's main config file is usually at `/etc/caddy/Caddyfile`. This is where we will configure the Caddy web server.
## Setting up HTTPS for secure connection
## Setting up HTTPS for Secure Connection
**Pre Requisite**: Make sure domain's DNS A record points to your VPS IP address.
If you haven't done this yet, go back to the [VPS setup guide](../setup-vps.md) and complete the domain name section.
Before starting, make sure your domain's DNS A record points to your VPS IP address. If you haven't done this yet, go back to the [VPS setup guide](../setup-vps.md) and complete the domain name section.
Open Caddy's config file
```bash
sudo vim /etc/caddy/Caddyfile
@@ -42,31 +38,32 @@ You'll see something like
}
```
Replace it with your domain name
Replace `:80` with your domain name:
```Caddyfile
domain.com {
root * /var/www/html # website files to server
root * /var/www/html # website files to serve
file_server # enable static file server
}
```
Caddy will automatically get TLS certificate for `domain.com`.
We need not to worry about provisioning certificates or renewning them.
Caddy will automatically get a TLS certificate for `domain.com`. You don't need to worry about provisioning certificates or renewing them - Caddy handles all of that automatically!
After making changes, reload Caddy configuration:
After making changes, reload Caddy
```bash
sudo systemctl reload caddy
```
Now visit `https://domain.com` (notice the `https`). HTTP traffic is secure and encrypted.
Now visit `https://domain.com` (notice the `https`). Your HTTP traffic is now secure and encrypted!
## Redirects
You probably want to redirect a few things:
* Visitors using `www.domain.com` -> redirect to `domain.com`
* Visitors using your server's IP address (`192.168.1.`) -> redirect to `domain.com`
* Visitors using `www.domain.com` → redirect to `domain.com`
* Visitors using your server's IP address (`192.168.1.1`) → redirect to `domain.com`
Add this block to your Caddyfile:
```Caddyfile
192.168.1.1,
@@ -75,17 +72,17 @@ www.domain.com {
}
```
This config sets up the redirects as mentioned. You can list multiple domains/addresses separated by commas or spaces.
All visitors will end up at `https://yourdomain.com`, which looks clean imo!!!
This config sets up the redirects as mentioned. You can list multiple domains/addresses separated by commas or spaces. All visitors will end up at `https://domain.com`, which keeps things clean and consistent!
After making changes, reload Caddy
Reload Caddy after making changes
```bash
sudo systemctl reload caddy
```
## Organizing Configuration
As we add more services, Caddyfile can get long and bloated. Caddy lets you split your configuration across multiple files!
As we add more services, the Caddyfile can get long and bloated. Caddy lets you split your configuration across multiple files!
### 1. Create the Config Directory
@@ -93,18 +90,17 @@ As we add more services, Caddyfile can get long and bloated. Caddy lets you spli
sudo mkdir -p /etc/caddy/conf.d
```
This directory will hold service specific config files, one file per service (e.g. `pokemon-api.Caddyfile`).
This directory will hold service-specific config files, one file per service (e.g., `pokemon-api.Caddyfile`).
### 2. Update Main Caddyfile
Add this line in the main Caddyfile
Add this line to the main Caddyfile
```Caddyfile
import conf.d/*.Caddyfile
```
It will load all `.Caddyfile` files from the `conf.d` directory.
We can put each service's config in its own file!
It will load all `.Caddyfile` files from the `conf.d` directory. We can put each service's config in its own file!
Right now we don't have any specific service, but soon we will have.
@@ -112,10 +108,15 @@ Right now we don't have any specific service, but soon we will have.
When something goes wrong, we can show a nice custom error page instead of Caddy's default.
There's a custom error page you can use [error.html](./error.html). It uses Caddy placeholders to show the error code and message.
Save it inside `/var/www` directory.
### 1. The Error Page
In your Caddyfile, add error_handler inside your domain block
There's a custom error page you can use: [error.html](./error.html). It uses Caddy placeholders to show the error code and message.
Save it inside the `/var/www` directory.
### 2. Configure Error Handling
In your Caddyfile, add `handle_errors` inside your domain block:
```Caddyfile
domain.com {
@@ -132,13 +133,13 @@ domain.com {
```
* `handle_errors` - Catches all error responses
* `root * /var/www` - Specifies here to find the error.html file
* `rewrite * /error.html` - shows error.html for all errors
* `templates` - Enables Caddy's templating
* `root * /var/www` - Specifies where to find the error.html file
* `rewrite * /error.html` - Shows error.html for all errors
* `templates` - Enables Caddy's templating
**To learn more** Check out [error handling](https://caddyserver.com/docs/caddyfile/directives/handle_errors) and [templates](https://caddyserver.com/docs/caddyfile/directives/templates) documentation
**Reference:** Check out [error handling](https://caddyserver.com/docs/caddyfile/directives/handle_errors) and [templates](https://caddyserver.com/docs/caddyfile/directives/templates) documentation.
Reload caddy as usual
After making changes, reload Caddy
```bash
sudo systemctl reload caddy
@@ -146,23 +147,21 @@ sudo systemctl reload caddy
## Reverse Proxy
Reverse proxy makes it easier to run multiple services running on one server without exposing multiple ports
We can have different subdomain for each service and reverse proxy will handle the routing.
When someone visits `pokemon.domain.com`, the reverse proxy looks at the request and forwards it to the correct service running on the server.
Reverse proxy makes it easier to run multiple services on one server without exposing multiple ports. We can have different subdomains for each service, and the reverse proxy will handle the routing. When someone visits `pokemon.domain.com`, the reverse proxy looks at the request and forwards it to the correct service running on the server.
Let's say we have a pokemon API running on port 8080, and it should accessible at `pokemon.domain.com`.
Let's say we have a pokemon API running on port 8080, and it should be accessible at `pokemon.domain.com`.
### 1. Set Up DNS
In domain's DNS settings, create an A record
- **Name**: `pokemon` (for `pokemon.domain.com`)
- **Value**: Server's IP address
In your domain's DNS settings, create an A record
* **Name**: `pokemon` (for `pokemon.domain.com`)
* **Value**: Server's IP address
Wait for few minutes for DNS to propagate.
Wait for a few minutes for DNS to propagate.
### 2. Create the Reverse Proxy Config
Create a new config file for the pokemon api
Create a new config file for the pokemon API
```bash
sudo vim /etc/caddy/conf.d/pokemon.Caddyfile
@@ -176,16 +175,14 @@ pokemon.domain.com {
}
```
Reload Caddy
After creating the config file, reload Caddy:
```bash
sudo systemctl reload caddy
```
Now visit `https://pokemon.domain.com` - Caddy will forward all traffic to your service and automatically get an HTTPS certificate for this domain.
Now visit `https://pokemon.domain.com` - Caddy will forward all traffic to your service and automatically get an HTTPS certificate for this domain!
I've included a template for reverse proxy block with error handling and redirects for `www` subdomain
Checkout the [`pokemon.Caddyfile`](./pokemon.Caddyfile) file. You can use as it as for setting up reverse proxies.
I've included a template for reverse proxy block with error handling and redirects for `www` subdomain. Check out the [`pokemon.Caddyfile`](./pokemon.Caddyfile) file. You can use it as a template for setting up reverse proxies.
**To learn more** check out [reverse proxy](https://caddyserver.com/docs/quick-starts/reverse-proxy) documentation.
**Reference:** Check out [reverse proxy](https://caddyserver.com/docs/quick-starts/reverse-proxy) documentation.

42
gitea/readme.md
View File

@@ -37,15 +37,13 @@ Copy the content of [docker-compose.yaml](./docker-compose.yaml) file to newly c
### 2. Reverse Proxy Setup
To make it Gitea accessible outside the server we need to setup a subdomain for Gitea `https://git.domain.com` and set up a reverse proxy with Caddy.
To make Gitea accessible outside the server, we need to set up a subdomain for Gitea at `https://git.domain.com` and set up a reverse proxy with Caddy.
Set Up DNS by creating an **A Record**
Create an **A Record** in your domain's DNS settings
* **Name**: `git` (for `git.domain.com`)
* **Value**: Server's IP address
Create a reverse proxy for `git.domain.com` domain
Create the config file in Caddy's config directory:
Create a reverse proxy for the `git.domain.com` domain in Caddy's config directory:
```bash
sudo vim /etc/caddy/conf.d/gitea.Caddyfile
@@ -61,7 +59,7 @@ sudo systemctl reload caddy
Change the `GITEA__server__ROOT_URL` environment variable inside the docker-compose file to the git subdomain.
Start the GITEA docker container
Start the Gitea Docker Container
```bash
docker compose up -d
@@ -73,23 +71,25 @@ Gitea is now running on port 3000 and will show an installation wizard.
## Installation Setup
**Database** SQLite just to keep it simple
Fill out the the details in installation wizard
**Site Title:** a cool name or just use default "Gitea"
**Database:** SQLite (just to keep it simple)
**Repository Root Path** keep the default`/data/git/repositories`
**Site Title:** A cool name or just use the default "Gitea"
**Server Domain** Gitea domain `git.domain.com`
**Repository Root Path:** Keep the default `/data/git/repositories`
**Server Domain:** Gitea domain `git.domain.com`
**SSH Port:** `2222`
**HTTP Port:** keep default`3000` or just use any available port
**HTTP Port:** Keep the default `3000` or just use any available port
**Gitea Base Url:** `https://git.domain.com`
**Gitea Base URL:** `https://git.domain.com`
**Server Settings:** Enable `Local Mode` and disable `Self Registeration` if installing for personal use.
**Server Settings:** Enable `Local Mode` and disable `Self Registration` if installing for personal use.
After this just click on **Install Gitea** button and your Gitea is ready to use
After this, just click on the **Install Gitea** button and your Gitea is ready to use!
---
@@ -159,10 +159,9 @@ environment:
- USER_GID=101
```
### 3. Generate SSH Keys on host
### 3. Generate SSH Keys on Host
The `git` user on your server needs to connect to the Gitea container to perform git operations.
Generate an SSH key that allows this connection.
The `git` user on your server needs to connect to the Gitea container to perform git operations. Generate an SSH key that allows this connection.
```bash
sudo -u git ssh-keygen -t ed25519 -f /home/git/.ssh/gitea_key -N ""
@@ -172,9 +171,7 @@ This creates two files:
* `/home/git/.ssh/gitea_key` - Private key (keep this secret!)
* `/home/git/.ssh/gitea_key.pub` - Public key
Also add the public key to authorized_keys.
This allows the git user to SSH into the container.
Also add the public key to `authorized_keys`. This allows the git user to SSH into the container.
```bash
sudo -u git cat /home/git/.ssh/gitea_key.pub | sudo -u git tee -a /home/git/.ssh/authorized_keys
@@ -195,14 +192,15 @@ EOF
sudo chmod +x /usr/local/bin/gitea
```
After all the changes restart the gitea container
After all the changes, restart the Gitea container
```bash
docker compose restart
```
### 5. Test SSH Access
Now users can add their SSH public keys to their Gitea accounts and use Git over SSH it should work perfectly fine.
Now users can add their SSH public keys to their Gitea accounts and use Git over SSH. It should work perfectly fine!
Try cloning a repository