Deploying Caddy as

What We Are Configuring and Why

In this guide, we will focus on creating a reliable and secure infrastructure for hosting web applications on your own VPS. The main task is to provide external access to applications running inside Docker containers via a domain name, while automatically securing the connection with HTTPS. To achieve this, we will use a combination of three key components:

• Docker: A platform for application containerization. Docker allows packaging applications with all their dependencies into isolated "containers," ensuring their portability and predictable operation in any environment. We will use Docker Compose to orchestrate multiple containers that make up a single application or service.
• Caddy: A modern web server and reverse proxy. Caddy stands out for its configuration simplicity and, most importantly, built-in support for automatic issuance and renewal of SSL/TLS certificates via Let's Encrypt. This eliminates the need to manually configure Certbot or other HTTPS tools, significantly simplifying the process.
• VPS (Virtual Private Server): A Virtual Private Server that will provide us with the necessary computing power and network resources to host our infrastructure.

Ultimately, the reader will have a fully configured system capable of securely and efficiently hosting one or more web applications (e.g., GitLab, Mattermost, WordPress, or custom SaaS applications) in Docker containers, accessible via domain names with automatic HTTPS. This is an ideal solution for developers, startups, and enthusiasts who want full control over their infrastructure without the high costs of cloud-managed services.

Alternatives: Cloud-managed vs. Self-hosted on VPS

There are two main approaches to deploying web applications:

• Cloud-managed services: Platforms such as Heroku, Netlify, AWS Elastic Beanstalk, Google App Engine offer high automation, scalability, and minimal administration effort. You simply upload your code, and the platform takes care of servers, scaling, databases, and HTTPS.
  Advantages: Simplicity, high availability, automatic scaling.
  Disadvantages: High cost with growth, less control over infrastructure, vendor lock-in, sometimes limited customization options.
• Self-hosted on VPS/Dedicated server: This approach involves renting a "bare metal" server (virtual or physical) and independently configuring the entire stack — operating system, web server, database, containerization, etc.
  Advantages: Full control over every aspect of the system, significantly lower cost in the long term (especially under moderate loads), flexibility in technology and configuration choices, data privacy.
  Disadvantages: Requires technical knowledge and time for setup and maintenance; responsibility for security and backups rests with you.

Choosing self-hosted on a VPS with Caddy and Docker is a golden mean for those seeking a balance between control, cost, and ease of use. Caddy significantly lowers the entry barrier for self-configuring HTTPS, and Docker simplifies application management.

What VPS Configuration is Needed for This Task

Choosing the right VPS configuration is critical for the stable operation of your applications. Requirements will depend on the number and resource intensity of the Docker containers you plan to run.

Minimum Requirements for a Basic Setup (Caddy + 1-2 Light Containers)

• CPU: 1-2 cores (e.g., Intel Xeon E3/E5 or AMD EPYC). For most web applications, one core is sufficient, but two will provide a performance buffer and better responsiveness.
• RAM: 2 GB. Docker and Caddy themselves consume little, but each application in a container requires its own memory. 2 GB is a comfortable minimum for the OS, Docker daemon, and a couple of undemanding services (e.g., a small WordPress blog without a heavy DBMS or a simple API service).
• Disk: 40-60 GB NVMe SSD. SSD significantly speeds up I/O operations, which is important for databases and fast container startup. NVMe offers even greater speed. 40-60 GB is sufficient for the OS, Docker images, containers, and a small amount of data. If large volumes of data are planned (e.g., file storage, logs, backups), more space will be required.
• Network: 100-200 Mbps. For most tasks, this is more than enough. Channel stability and low latency are more important.

Specific VPS Plan for the Task

For deploying Caddy with 3-5 Docker containers (e.g., GitLab, Mattermost, or several microservices), the following configuration plan is recommended:

• CPU: 2-4 cores (e.g., Intel Xeon E5-2690v4 or AMD EPYC 7002 series). This will provide sufficient performance for handling requests and background container tasks.
• RAM: 4-8 GB. For more demanding applications such as GitLab, Mattermost, or a Minecraft server, 4 GB is the minimum; 8 GB will provide significantly more flexibility and stability.
• Disk: 80-160 GB NVMe SSD. GitLab, Minecraft, and other similar applications can occupy significant disk space. NVMe SSD will ensure high-speed data operations.
• Network: 500 Mbps - 1 Gbps. High bandwidth will be beneficial for applications with a large number of users or intensive traffic.

You can consider a VPS with the specified characteristics to get an optimal price-to-performance ratio for this task. Ensure that the chosen plan includes a public IPv4 address, which is necessary for accessing your services from the internet and for Let's Encrypt to function.

When a Dedicated Server is Needed, Not a VPS

A dedicated server becomes the preferred choice when:

• High performance and stability: Maximum and predictable performance is required without "noisy neighbors" on a single physical server.
• Large data volumes: Hundreds of gigabytes or terabytes of data are planned for storage.
• Complex computations: Specialized processors (e.g., GPUs for machine learning) or a very large number of cores are needed.
• Strict security/compliance requirements: Full physical control over the hardware is required.
• Massive traffic: Very high network traffic is expected (tens of TB per month).

For most tasks described in this guide (GitLab for a team, Mattermost, Minecraft for friends), a powerful VPS will suffice. However, if you are launching a large SaaS project with thousands of users or a high-load crypto node, consider a suitable dedicated server.

Location: What it Affects

The choice of VPS location has several key aspects:

• Latency: The closer the server is to your primary audience, the lower the latency will be, and the faster pages will load for end-users. For a European audience, choose a server in Europe; for an American audience, choose one in North America.
• Regulatory requirements: In some jurisdictions, there are strict data storage laws (e.g., GDPR in the EU). The choice of server location can affect compliance with these requirements.
• Cost: VPS prices may vary slightly depending on the region.

For most tasks, if your audience is distributed, choose a location that is geographically close to you or your primary user group.

Server Preparation

After gaining access to your new VPS, you need to perform a series of initial configurations to ensure security and ease of use. We will be using Ubuntu Server 24.04/26.04 LTS as the operating system.

It is assumed that you have accessed the server via SSH as the root user or another user with sudo privileges.

1. System Update

First, let's update all packages to their latest versions.

sudo apt update          # Updates the list of available packages
sudo apt upgrade -y      # Upgrades all installed packages
sudo apt autoremove -y   # Removes unnecessary packages

2. Creating a New User with Sudo Privileges (if you are working as root)

Working as the root user is insecure. Let's create a new user and grant them sudo privileges.

sudo adduser username    # Replace 'username' with your desired username. Follow the prompts to create a password.
sudo usermod -aG sudo username # Adds the user to the sudo group to grant administrator privileges.

Now, exit the current SSH session (exit) and log in as the new user:

ssh username@your_vps_ip # Replace 'username' and 'your_vps_ip'

3. Configuring SSH Keys for Secure Access

Using SSH keys is much more secure than passwords. If you don't already have an SSH key, generate one on your local machine:

ssh-keygen -t ed25519 -C "[email protected]" # Creates a new SSH key (ed25519 is more secure)

Then, copy the public key to your VPS:

ssh-copy-id username@your_vps_ip # Copies the public key to the server

Now you can log in to the server without a password. After verifying that SSH keys work, it is recommended to disable password login for root and your new user, and also to disallow root login.

sudo nano /etc/ssh/sshd_config # Opens the SSH server configuration file

Find and change the following lines:

PermitRootLogin no
PasswordAuthentication no

Save changes (Ctrl+X, Y, Enter) and restart the SSH server:

sudo systemctl restart sshd # Restarts the SSH service

Important: Make sure you can log in with an SSH key before disabling password login! Otherwise, you might lose access to the server.

4. Installing and Configuring a Firewall (UFW)

UFW (Uncomplicated Firewall) is an easy-to-use interface for configuring iptables. It is necessary to restrict access to the server only to the required ports.

sudo apt install ufw -y # Installs UFW
sudo ufw allow OpenSSH  # Allows SSH (port 22)
sudo ufw allow http     # Allows HTTP (port 80)
sudo ufw allow https    # Allows HTTPS (port 443)
sudo ufw enable         # Enables UFW. Confirm with 'y'.
sudo ufw status verbose # Checks UFW status

5. Installing Fail2ban for Brute-Force Protection

Fail2ban scans service logs (SSH, web servers, etc.) for suspicious activity (e.g., multiple failed login attempts) and temporarily or permanently blocks attackers' IP addresses using firewall rules.

sudo apt install fail2ban -y # Installs Fail2ban
sudo systemctl enable fail2ban # Enables Fail2ban to start automatically on boot
sudo systemctl start fail2ban  # Starts the Fail2ban service
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local # Creates a local copy of the config for modifications
sudo nano /etc/fail2ban/jail.local # Edits the configuration

In the jail.local file, you can configure parameters such as bantime (block time), findtime (period during which failed attempts are counted), and maxretry (maximum number of attempts). Make sure the [sshd] section is enabled (enabled = true). You can increase bantime, for example, to 1h or even 1d.

[DEFAULT]
bantime = 1h
findtime = 10m
maxretry = 5

[sshd]
enabled = true
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s

Save changes and restart Fail2ban:

sudo systemctl restart fail2ban # Restarts Fail2ban to apply changes
sudo fail2ban-client status sshd # Checks SSH protection status

Software Installation — Step-by-Step

Now that the server is prepared, let's proceed with installing the main software: Docker, Docker Compose, and Caddy.

1. Installing Docker Engine (relevant for 2026)

We will install Docker from the official Docker repository to always have the latest versions. Current Docker Engine versions for 2026 will likely be in the 25.x-26.x range.

# Updates packages and installs dependencies
sudo apt update && sudo apt install -y ca-certificates curl gnupg lsb-release

# Adds Docker's official GPG key
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

# Adds the Docker repository to APT sources
echo \
  "deb [arch="$(dpkg --print-architecture)" signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
  "$(. /etc/os-release && echo "$VERSION_CODENAME")" stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# Updates package lists with the new repository
sudo apt update

# Installs Docker Engine, Docker CLI, and containerd
sudo apt install -y docker-ce docker-ce-cli containerd.io

# Adds the current user to the docker group to work without sudo
sudo usermod -aG docker "$USER"

# Applies changes for the Docker group (requires re-login or reboot)
# But it's better to just re-login or run 'newgrp docker'
newgrp docker

# Verifies Docker installation
docker run hello-world

The docker run hello-world command should successfully download and run a test container, confirming the correct Docker installation.

2. Installing Docker Compose

Docker Compose is a tool for defining and running multi-container Docker applications. It comes as part of Docker Engine since version 2.x.

# Checks Docker Compose version (Docker Compose v2.x is shipped as a Docker CLI plugin)
docker compose version

If the docker compose version command returns an error or a very old version, you might need to install it separately. However, for Ubuntu 24.04/26.04 and Docker Engine 25.x+, it should be available by default.

3. Installing Caddy (relevant for 2026)

Caddy can be installed from the official Caddy repository, which ensures you get the latest stable versions (Caddy 2.x).

# Installs dependencies for adding the HTTPS repository
sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https

# Adds Caddy's GPG key
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg

# Adds the Caddy repository to APT sources
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list

# Updates package lists with the new repository
sudo apt update

# Installs Caddy
sudo apt install -y caddy

# Checks Caddy service status
sudo systemctl status caddy

The Caddy service should be installed and running. If it's not running, start it: sudo systemctl start caddy.

Configuration

Now that all components are installed, it's time to configure their interaction. We will set up Caddy as a reverse proxy for Docker containers, using Docker Compose to define our applications.

1. Preparing Docker Network Infrastructure

For Caddy to interact with your Docker containers using their internal names, they need to be placed in a single custom Docker network.

# Create a custom Docker network for Caddy and applications
docker network create caddy_network

We will specify this network in the docker-compose.yml files for our applications and for Caddy itself.

2. Caddyfile Configuration

Caddy uses the file Caddyfile for its configuration. We will set it up to proxy traffic to our Docker containers.

sudo nano /etc/caddy/Caddyfile # Open the main Caddy configuration file

Remove the existing content and paste the following. Replace your-app.example.com and another-app.example.com with your actual domain names, and app_container_name and another_app_container_name with the names of your Docker containers.

# Global Caddy settings
{
    # Specifies that Caddy should use Google DNS servers for Let's Encrypt
    # This can be useful if your VPS has issues resolving DNS
    # acme_dns google # Uncomment if you are using a DNS provider that supports ACME DNS challenge
    # email [email protected] # Specify your email for Let's Encrypt notifications
}

# Configuration for the first application
your-app.example.com {
    # Proxy all traffic to the Docker container
    reverse_proxy app_container_name:80

    # Additional headers for better compatibility and security
    header {
        Strict-Transport-Security "max-age=31536000; includeSubDomains"
        X-Frame-Options DENY
        X-Content-Type-Options nosniff
        X-XSS-Protection "1; mode=block"
    }

    # Request logging
    log {
        output file /var/log/caddy/your-app.log
        format json
    }

    # Gzip compression (optional, but recommended)
    encode gzip
}

# Configuration for the second application (example)
another-app.example.com {
    reverse_proxy another_app_container_name:8080 # Specify the port your second application is listening on

    header {
        Strict-Transport-Security "max-age=31536000; includeSubDomains"
        X-Frame-Options DENY
        X-Content-Type-Options nosniff
        X-XSS-Protection "1; mode=block"
    }

    log {
        output file /var/log/caddy/another-app.log
        format json
    }

    encode gzip
}

# You can also add a directive for static files if Caddy will serve them
# example.com {
#     root  /var/www/html
#     file_server
# }

sudo mkdir -p /var/log/caddy
sudo chown caddy:caddy /var/log/caddy # Grant permissions to the caddy user
sudo systemctl restart caddy # Restart Caddy to apply the new Caddyfile
sudo systemctl status caddy  # Check that Caddy started successfully

mkdir ~/my_web_app
cd ~/my_web_app
nano docker-compose.yml

version: '3.8'

services:
  # Service name that Caddy will use for proxying
  # Ensure it matches the name in the Caddyfile (e.g., 'app_container_name')
  mywebapp:
    image: nginx:latest # Use the latest Nginx image
    container_name: mywebapp_container # Explicit container name
    restart: unless-stopped
    ports:
      - "80" # Nginx listens on port 80 inside the container
    networks:
      - caddy_network # Connect the container to the Caddy network

networks:
  caddy_network:
    external: true # Specify that the network already exists and was created manually

docker compose up -d # Start the container in detached mode

sudo nano /etc/caddy/Caddyfile

# ... other settings ...

# Configuration for your new application
my-nginx-app.example.com { # Replace with your actual domain
    reverse_proxy mywebapp:80 # Service name from docker-compose.yml and internal port
    log {
        output file /var/log/caddy/my-nginx-app.log
        format json
    }
    encode gzip
}

# ... remaining settings ...

sudo systemctl reload caddy # Reload Caddy configuration without stopping the service

nano ~/my_web_app/.env

DB_PASSWORD=MyStrongPassword123
API_KEY=supersecretkeyabc123

version: '3.8'

services:
  mywebapp:
    image: mycustomapp:latest
    container_name: mywebapp_container
    restart: unless-stopped
    environment:
      - DB_PASSWORD=${DB_PASSWORD} # Pass variable from .env
      - API_KEY=${API_KEY}
    networks:
      - caddy_network

networks:
  caddy_network:
    external: true