Securing Your Dokploy Instance: From Firewall to Traefik Hardening

Dokploy gives you a deployment platform that rivals Heroku and Vercel, but with one critical difference: you own the server. That ownership comes with responsibility. A default Dokploy installation on a fresh VPS is functional but not hardened. If you have already installed Dokploy on your VPS, the next step is locking it down before you push a single production workload.

This guide covers security hardening at every layer: the operating system, Dokploy itself, its Traefik reverse proxy, the Docker runtime, and the underlying infrastructure. Each section includes concrete commands and configurations you can apply immediately.

Server-Level Hardening

Before touching Dokploy's configuration, secure the base operating system. Every exposed service is an attack surface, and the goal is to reduce that surface to the absolute minimum.

SSH Key Authentication and Lockdown

Password-based SSH is the most common entry point for brute-force attacks. Disable it entirely and use key-based authentication:

# Generate an SSH key pair on your local machine (if you haven't already)
ssh-keygen -t ed25519 -C "your_email@example.com"

# Copy your public key to the server
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@your-server-ip

# On the server, edit the SSH config
sudo nano /etc/ssh/sshd_config

Set the following directives in /etc/ssh/sshd_config:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
AllowUsers yourusername

Restart the SSH daemon to apply changes:

sudo systemctl restart sshd

The AllowUsers directive is often overlooked but important. It restricts SSH access to only the specified user account, so even if another system account exists, it cannot be used to log in remotely.

Non-Root User Setup

Running Dokploy services as root is unnecessary and dangerous. Create a dedicated user with sudo privileges:

adduser deployer
usermod -aG sudo deployer
usermod -aG docker deployer

Adding the user to the docker group allows them to manage containers without sudo, which is necessary for Dokploy operations. Log in as this user for all subsequent administration.

UFW Firewall Configuration

Uncomplicated Firewall (UFW) provides a straightforward interface for iptables. For a Dokploy server, you need exactly three ports open:

# Reset to default deny
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Allow SSH (change port if you've moved it)
sudo ufw allow 22/tcp

# Allow HTTP and HTTPS for Traefik
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# Enable the firewall
sudo ufw enable
sudo ufw status verbose

Notice that port 3000 (Dokploy's web UI) is intentionally not opened. After you configure a domain and Traefik proxy for the dashboard, direct access to port 3000 should be blocked. More on this in the next section.

Fail2ban and Automatic Updates

Install fail2ban to automatically ban IPs that show malicious patterns:

sudo apt install fail2ban -y
sudo systemctl enable fail2ban
sudo systemctl start fail2ban

The default configuration monitors SSH and bans IPs after 5 failed attempts for 10 minutes. For a Dokploy server, the defaults are adequate since your SSH is already key-only.

Enable automatic security patches so critical vulnerabilities get patched without manual intervention:

sudo apt install unattended-upgrades -y
sudo dpkg-reconfigure -plow unattended-upgrades

This configures the system to automatically download and install security updates from the Ubuntu security repository.

Dokploy-Specific Hardening

Disable Direct Port 3000 Access

After your initial Dokploy setup, you accessed the web UI at http://your-ip:3000. Once you have configured a domain (e.g., deploy.yourdomain.com) and Traefik is routing traffic to the dashboard, block direct access to port 3000. The UFW configuration above already handles this at the firewall level since we only allow ports 22, 80, and 443.

To verify port 3000 is not reachable from outside, test from a different machine:

curl -v http://your-server-ip:3000 --connect-timeout 5

This should time out. If it connects, your firewall rules are not applied correctly.

Strong Admin Credentials and Session Security

Use a unique, high-entropy password for the Dokploy admin account. Dokploy does not currently support TOTP/2FA natively, so the strength of your admin password and the security of the Traefik layer in front of it are your primary defenses against unauthorized dashboard access.

Deployment Notifications

Configure Dokploy's notification system to alert on failed deployments. Unexpected deployment failures can indicate compromised build pipelines or tampered Dockerfiles. Dokploy supports Slack, Discord, Telegram, and email notifications. Enable at least one channel and monitor it.

Traefik TLS and Security Headers

Dokploy uses Traefik as its reverse proxy and automatic TLS certificate manager. The default configuration handles Let's Encrypt certificates, but you should harden the TLS settings and add security headers.

TLS Configuration

Traefik's dynamic configuration can be extended to enforce strong TLS. Create or modify the Traefik configuration to set minimum TLS version and preferred cipher suites:

# In Traefik's dynamic configuration
tls:
  options:
    default:
      minVersion: VersionTLS12
      cipherSuites:
        - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
        - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
        - TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
        - TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
      sniStrict: true

Setting sniStrict: true ensures Traefik rejects connections that don't match a configured hostname, preventing certificate-based information leaks.

HTTP-to-HTTPS Redirect

Ensure all HTTP traffic is redirected to HTTPS. Dokploy's Traefik setup typically handles this, but verify it is active. In Traefik's entrypoints configuration:

entryPoints:
  web:
    address: ":80"
    http:
      redirections:
        entryPoint:
          to: websecure
          scheme: https
          permanent: true
  websecure:
    address: ":443"

Security Headers Middleware

Add a middleware that injects security headers into every response:

http:
  middlewares:
    security-headers:
      headers:
        stsSeconds: 31536000
        stsIncludeSubdomains: true
        stsPreload: true
        forceSTSHeader: true
        frameDeny: true
        contentTypeNosniff: true
        browserXssFilter: true
        referrerPolicy: "strict-origin-when-cross-origin"
        contentSecurityPolicy: "default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'"
        customResponseHeaders:
          X-Robots-Tag: "noindex, nofollow"

The X-Robots-Tag: noindex, nofollow header is particularly relevant for Dokploy dashboards and staging environments that should never appear in search engine results.

Rate Limiting

Protect against brute-force login attempts and API abuse with Traefik's rate limiting middleware:

http:
  middlewares:
    rate-limit:
      rateLimit:
        average: 100
        burst: 50
        period: 1m

Apply this middleware to your Dokploy dashboard route. For your deployed applications, you may want different rate limits depending on expected traffic patterns.

Docker Security

Container Isolation and Privileges

Never run application containers with the --privileged flag unless absolutely required. Privileged containers have full access to the host kernel, which negates container isolation entirely. Dokploy's application containers do not need privileged access.

In your Dockerfiles and compose configurations, follow the principle of least privilege:

Run application processes as a non-root user inside the container (USER node, USER www-data, etc.)
Use read-only root filesystems where possible (--read-only)
Drop all Linux capabilities and add back only what is needed (--cap-drop=ALL --cap-add=NET_BIND_SERVICE)
Limit container memory and CPU to prevent resource exhaustion attacks

Docker Socket Protection

This is the most critical Docker security consideration for Dokploy. Dokploy requires access to the Docker socket (/var/run/docker.sock) to manage containers, build images, and orchestrate deployments. The Docker socket effectively grants root access to the host, which is why securing every layer above it matters so much.

Mitigations for Docker socket exposure:

Network isolation: Ensure the Docker API is never exposed on a network port. Dokploy uses the local socket, which is correct. Never add -H tcp://0.0.0.0:2375 to Docker daemon options.
User namespace remapping: Configure Docker's userns-remap to map the root user inside containers to an unprivileged user on the host. Note that this can cause compatibility issues with some images and should be tested.
Regular auditing: Periodically inspect running containers with docker ps and docker inspect to ensure no unexpected containers are running.

Image Security and Docker Content Trust

Enable Docker Content Trust to verify image signatures:

export DOCKER_CONTENT_TRUST=1

Keep your base images updated. Stale images accumulate known vulnerabilities. In Dokploy, this means periodically rebuilding and redeploying your applications even if your application code has not changed. Scan images with tools like docker scout cves or Trivy:

# Scan an image for known vulnerabilities
docker scout cves your-image:latest

Infrastructure-Level Security

Application-level hardening (everything above) protects against targeted attacks: brute force, injection, misconfigurations. But volumetric DDoS attacks operate at a different scale entirely. A 50 Gbps UDP flood will overwhelm your server's network interface long before any firewall rule or Traefik middleware has a chance to process the packets.

This is where infrastructure-level mitigation is essential. MassiveGRID's Dokploy hosting includes 12 Tbps DDoS protection that filters malicious traffic at the network edge, before it reaches your server. Volumetric attacks are absorbed by the scrubbing infrastructure, while legitimate traffic passes through to your Dokploy instance unaffected.

For production workloads that require failover protection, HA Cloud Dedicated Servers add automatic failover. If the underlying hardware fails, your Dokploy instance is automatically migrated to healthy infrastructure with no manual intervention required.

Independent Resource Scaling for Security Monitoring

Running security monitoring tools alongside Dokploy (Prometheus for metrics collection, Grafana for dashboards, Loki for log aggregation) requires additional RAM and CPU that should not compete with your application workloads. On a MassiveGRID VPS, you can scale RAM independently to accommodate monitoring overhead without overpaying for CPU you do not need. If builds become the bottleneck, scale CPU independently instead. This granular approach means you can run a proper security monitoring stack without the cost of jumping to a larger fixed-size plan.

Backup Security

Dokploy includes a built-in backup feature for databases (PostgreSQL, MySQL, MariaDB, MongoDB). Configure automated backups and store them on separate infrastructure from your application server. A compromised server should not also mean compromised backups.

Key backup practices:

Encrypt backups at rest: Use GPG or age encryption on backup archives before transferring to remote storage.
Separate storage credentials: The S3 or remote storage credentials used for backups should be scoped to write-only access from the Dokploy server. An attacker who compromises the server should not be able to delete existing backups.
Test restores regularly: A backup you have never restored is not a backup. Schedule monthly restore tests to a staging environment.
Retain multiple generations: Keep at least 7 daily and 4 weekly backup copies to protect against delayed detection of data corruption or compromise.

MassiveGRID for Dokploy

12 Tbps DDoS Protection — Volumetric attack mitigation at the network edge, before traffic reaches your Dokploy instance
Independent Resource Scaling — Scale CPU, RAM, and storage separately. Add resources for security monitoring without overpaying
Dedicated VPS Resources — No noisy neighbors affecting your security-critical workloads
HA Cloud Dedicated — Automatic failover with 100% uptime SLA for production Dokploy deployments
4 Global Data Centers — NYC, London, Frankfurt, Singapore with consistent security posture across regions

Explore Dokploy Hosting on MassiveGRID →

Putting It All Together

Security is layered. No single measure is sufficient, but each layer reduces the attack surface and raises the cost of a successful breach:

OS layer: SSH keys, UFW, fail2ban, automatic security updates
Dokploy layer: Dashboard behind Traefik, strong credentials, deployment alerts
Traefik layer: TLS 1.2+, security headers, rate limiting, HSTS
Docker layer: Non-root containers, no unnecessary privileges, socket protection, image scanning
Infrastructure layer: DDoS protection, network-edge filtering, HA failover
Backup layer: Encrypted, off-server, tested restores

If you are running Dokploy on infrastructure without DDoS protection, your application-level hardening is irrelevant against volumetric attacks. If you have DDoS protection but no firewall rules, automated scanners will find your open ports. Defense in depth is not optional for production deployments.

For a walkthrough of the initial setup, see our guide on installing Dokploy on a VPS. To understand which server tier fits your security requirements, read choosing the best VPS for Dokploy. And if you are scaling to multiple nodes, the multi-node Docker Swarm guide covers securing inter-node communication across a distributed Dokploy cluster.