Domains & SSL
Point a custom domain at your app and let DeployOS handle HTTPS automatically.
DeployOS terminates HTTPS for you automatically using whichever reverse proxy you chose for the server — Traefik or Caddy. You don't run certbot, you don't manage certificate renewal, and you don't hand-edit any proxy config.
Connect a domain
- Point your domain's A record at your server's IP address, at your DNS provider.
- On the app's Config (or Overview) tab, set the Custom domain.
- Deploy (or redeploy) the app. DeployOS publishes a route for that domain to the server's reverse proxy, which requests a certificate automatically the first time traffic hits it over HTTPS.
DNS cutover assistant
Because DNS propagation isn't instant, the domain card on an app has a live auto-check: once you've set a domain, it polls in the background — checking both that the A record now resolves to your server and that a certificate has actually been issued — and shows a banner the moment both are true. You don't need to keep manually refreshing to see if it's live yet.
Traefik vs Caddy
Both are fully supported reverse proxies; pick one per server when you add it.
| Traefik | Caddy | |
|---|---|---|
| Config style | Dynamic YAML route files, auto-discovered | Caddyfile, one site block per app |
| Certificates | Automatic via Let's Encrypt | Automatic via Let's Encrypt |
| Default | Yes | No |
Neither requires you to touch the underlying config directly — DeployOS generates and publishes it as part of every deploy.
Moving domains between apps
If you point a domain at a new app after it was previously used by a different one, DeployOS removes the old route claiming that domain before publishing the new one — so a stale route can't keep serving the wrong app after a domain moves.
Adopted servers with an existing proxy
If a server already had Traefik or Caddy running before DeployOS bootstrapped it, bootstrap detects the real config path that proxy reads from and symlinks DeployOS's expected path to it — so routes it generates get picked up by the proxy that's actually running, not a second one it would otherwise fight for port 443.