Caddy Server VPS

Who it suits

Anyone who wants HTTPS without managing certificates: a static site, or a reverse proxy for an app listening on localhost, such as n8n, Uptime Kuma or a Node.js app. A Caddyfile is shorter than the nginx equivalent; nginx has more examples online.

Which plan

Budget is plenty for Caddy itself. Size the plan for the app behind it.

What we install

Caddy gets and renews TLS certificates on its own. Edit one Caddyfile with your domain and it serves your site over HTTPS, or proxies to an app on another port.

From order to ready

1. Server ready. We email you when the server is running, and you can log in with SSH. The installer starts on that same first boot.
2. Installer running. It logs to /var/log/vps9-setup.log; tail -f it to watch.
3. Application ready. This can be minutes after SSH works. The installer writes its exit code to /var/lib/vps9-setup.exit; a value of 0 means installation succeeded. Caddy is ready when http://<your IPv4>/ shows its default page. It gets a certificate the first time it loads a Caddyfile naming a domain that points at the server.

What you still do

1. Point your domain at the server.
2. Edit /etc/caddy/Caddyfile: replace :80 with your domain.
3. Run systemctl reload caddy.

Exposure and security

Ports 80 and 443 are open for Caddy. There's no admin page to claim; Caddy's admin API listens on localhost only.

Backups and upgrades

Caddy updates with the system's packages, from Caddy's repository on Ubuntu and Debian and from COPR (or EPEL) on the Red Hat family. Back up /etc/caddy and your site files. We run the hardware, the network and the first-boot install; after that, Caddy is yours to run, and we don't manage or update it for you. Off-site backups of the whole disk are an optional paid add-on; they copy the disk as it is at one moment, so keep the app's own backups as well.