Today I had a chance to try Caddy for dev purpose, and you guess what, it was extremely easy and funny. Only two steps and boom, you got a secured website almost instantly.
Here are the steps I followed:
Install Caddy on Ubuntu/Debian
Check their documentation for another OS/installation method.
1
2
3
4
5
| sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install caddy
|
Edit Caddyfile
and restart the service
1
| sudo vim /etc/caddy/Caddyfile
|
1
2
3
| dev-api.your-domain.com
reverse_proxy 127.0.0.1:8000
|
1
2
3
| sudo systemctl restart caddy
# or
sudo caddy reload
|
That’s it, you can now browse https://dev-api.your-domain.com
.
In my case, a REST API service was running on port 8000 and I configured Caddy as a reverse proxy.
Configuring Caddy should be easy for other use cases as well, I’m pretty sure.
If you were to configure multiple domains:
1
2
3
4
5
6
7
| api.domain.com {
reverse_proxy 127.0.0.1:8000
}
app.domain.com {
reverse_proxy 127.0.0.1:3000
}
|
If you were to serve SPA(Single Page Application):
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
| prod.domain.com {
encode zstd gzip
root * /home/user/domain.com/prod
file_server
try_files {path} /index.html
}
staging.domain.com {
encode zstd gzip
root * /home/user/domain.com/staging
file_server
try_files {path} /index.html
}
qa.domain.com {
encode zstd gzip
root * /home/user/domain.com/qa
file_server
try_files {path} /index.html
}
|
Happy coding!