Video coming soon…

🔒 Setup Caddy — Automatic HTTPS Web Server & Reverse Proxy

Deploy Caddy on Ubuntu with Docker — the modern web server that automatically obtains and renews Let's Encrypt SSL certificates, with a simple two-line config for reverse proxying any service to your domain.

⚠️ This script is provided for demo and testing purposes only. Not intended for production use.

📦 Resources & Setup Scripts

Grab the automated bash script from GitHub to follow along with the video.

Automated install script — Caddy with automatic HTTPS in one command.
View on GitHub

Quick Install:

wget https://raw.githubusercontent.com/mhmdali94/Docker/main/networking/caddy/caddy-ubuntu.sh
chmod +x caddy-ubuntu.sh
sudo bash caddy-ubuntu.sh

Tutorial Steps

1 Download & Run the Script

The script installs Docker and starts Caddy with a basic Caddyfile. Ports 80 and 443 are mapped for HTTP/HTTPS, and port 2019 for the admin API (localhost only). Caddy will serve a default page on port 80 immediately.

wget https://raw.githubusercontent.com/mhmdali94/Docker/main/networking/caddy/caddy-ubuntu.sh
chmod +x caddy-ubuntu.sh
sudo bash caddy-ubuntu.sh

2 Edit the Caddyfile

The Caddyfile is the heart of Caddy's configuration. To reverse proxy a domain to a local service, add just two lines. Make sure your domain's DNS A record points to your server's IP before Caddy attempts to get a certificate:

# /etc/caddy/Caddyfile
yourdomain.com {
    reverse_proxy localhost:8080
}

anotherdomain.com {
    reverse_proxy localhost:9000
}

3 Reload Caddy & Get HTTPS

After editing the Caddyfile, reload Caddy to apply the new configuration. Caddy will automatically contact Let's Encrypt, prove domain ownership via HTTP challenge, and install a valid SSL certificate — all without any additional commands:

docker exec caddy caddy reload --config /etc/caddy/Caddyfile

4 Verify HTTPS & Test Your Site

Open your domain in a browser — you should see a valid HTTPS padlock and your service proxied correctly. Caddy automatically redirects HTTP to HTTPS. Check the certificate details to confirm it was issued by Let's Encrypt. Caddy will renew certificates automatically 30 days before expiry — no cron jobs needed.

Ports Used

PortPurpose
80HTTP (redirected to HTTPS automatically)
443HTTPS — encrypted web traffic
2019Caddy admin API (localhost only)

Overview

Caddy is a modern, open-source web server written in Go that makes HTTPS automatic and effortless. Unlike Nginx or Apache, Caddy obtains and renews Let's Encrypt SSL/TLS certificates without any manual configuration — just point a domain at your server and add it to the Caddyfile. Caddy is also an excellent reverse proxy, load balancer, and static file server with a configuration syntax so simple that a full HTTPS reverse proxy setup takes just 2 lines.

Why Use It

Caddy eliminates the most painful part of running web services: SSL certificate management. With Nginx, you need Certbot, renewal cron jobs, and complex server block configuration. With Caddy, automatic HTTPS is the default — not an add-on. The Caddyfile format is dramatically simpler than Nginx or Apache configs, making it ideal for homelab users and developers who want HTTPS without the certificate management headache.

When You Need It

    Who Should Use It

      Real Use Cases

        Main Features

          How to Use After Installation

            Security Best Practices

              Ports and Firewall Notes

              Open ports 80 (HTTP) and 443 (HTTPS) in your server's firewall — both are required. Port 80 is needed for Let's Encrypt HTTP-01 challenge to obtain certificates. Caddy automatically redirects all HTTP traffic to HTTPS after certificates are obtained. Port 2019 (admin API) must be bound to localhost only and never exposed externally.

              Backup and Maintenance

                Common Mistakes

                  Troubleshooting

                    Alternatives

                    Nginx Proxy Manager is a GUI-based reverse proxy that is easier for non-technical users but less scriptable. Traefik is a Docker-native reverse proxy that auto-discovers services from Docker labels — excellent for dynamic Docker environments. Nginx with Certbot is more complex but widely documented and used in production. HAProxy excels at pure load balancing but lacks automatic SSL. For simple use cases, Nginx Proxy Manager is often easier; for config-as-code, Caddy is superior.

                    When Not to Use It

                    Don't use Caddy if you need GUI-based proxy management for non-technical team members — Nginx Proxy Manager is better. If you have a highly dynamic Docker environment where services start and stop frequently, Traefik's auto-discovery from Docker labels is more efficient. For advanced Nginx-specific configurations like complex rewrite rules or Lua scripting, stick with Nginx.

                    PrismaTechWork Professional Help

                    PrismaTechWork provides end-to-end infrastructure services — from initial deployment and security hardening to ongoing monitoring, automated backups, and dedicated support. Whether you need a single-server setup or a multi-site network, our team ensures your infrastructure is built right, secured properly, and maintained reliably.

                      Contact Us

                      Frequently Asked Questions

                      What makes Caddy different from Nginx?

                      Caddy's most distinctive feature is automatic HTTPS — it obtains and renews Let's Encrypt SSL certificates with zero configuration. With Nginx, you must manually configure Certbot and renewal cron jobs. Caddy's Caddyfile is also far simpler — a reverse proxy with HTTPS is 2-3 lines versus 50+ lines for the equivalent Nginx config.

                      Does Caddy automatically handle SSL certificate renewal?

                      Yes. Caddy automatically renews all managed certificates before they expire — no cron jobs, no certbot, no manual intervention. Certificates are stored in a persistent volume and survive container restarts. Caddy handles OCSP stapling, HSTS headers, and HTTP to HTTPS redirects automatically.

                      How does the Caddyfile work?

                      The Caddyfile is Caddy's configuration file — a simple, human-readable format. To reverse proxy a domain to a local service, you write just two lines: the domain name and 'reverse_proxy localhost:PORT'. Caddy reads this file, obtains HTTPS certificates automatically, and serves traffic.

                      Can Caddy serve static files?

                      Yes. Use the 'file_server' directive to serve files from a directory with automatic directory browsing, compression, and range requests. For static sites, Caddy is often simpler and faster than Nginx.

                      Does Caddy support load balancing?

                      Yes. Caddy's reverse_proxy directive supports multiple upstream backends with round-robin, random, least-connections, and IP-hash load balancing. You can configure health checks, passive health monitoring, failover, and retries.

                      Can I use wildcard SSL certificates with Caddy?

                      Yes, with DNS challenge. Wildcard certificates (*.yourdomain.com) require DNS validation. Caddy supports DNS challenge for many DNS providers through caddy-dns plugins. Configure your DNS provider API credentials and Caddy will automatically obtain and renew wildcard certificates.

                      How does Caddy compare to Nginx Proxy Manager?

                      Nginx Proxy Manager provides a web GUI for managing reverse proxies — ideal for non-technical users. Caddy is config-file driven and better for developers who want simplicity and automation without a GUI. Both handle SSL and reverse proxying well — choose based on whether you prefer GUI or config-file management.

                      What is Caddy's admin API?

                      Caddy exposes a REST admin API on port 2019 (localhost only by default) for dynamic configuration changes without reloading. You can add, modify, or remove routes, upstreams, and TLS settings at runtime via HTTP requests — ideal for dynamic environments where services are added and removed programmatically.