Production Hardening Guide

This guide covers the baseline hardening for a production Dokploy instance: the host it runs on, the Docker engine, Dokploy itself, the Traefik reverse proxy, and the databases it manages. It's written to be implemented end-to-end in an afternoon, and to double as a checklist you can walk through directly (see the Final Checklist and Compliance Mapping).

Each ⬜ below is one control to implement and check off; Section 8 collects all of them into a single table.

1. Shared Responsibility

Dokploy secures the application layer — authentication, authorization, TLS automation, secrets referencing, audit trails. You're responsible for the infrastructure it runs on: the host OS, the network perimeter, the database engine's placement, and backup storage security.

2. Host OS

Run this section on the box before (or right after) installing Dokploy — as root or via sudo.

• ⬜ Ubuntu or Debian LTS — the only OS families Dokploy's automated security check currently targets.
• ⬜ unattended-upgrades installed and enabled for automatic security patches.
• ⬜ SSH: key-based authentication only, root login disabled, password authentication disabled.
• ⬜ Non-standard SSH port (optional — reduces automated scan noise, not a substitute for the above).
• ⬜ Fail2Ban (or CrowdSec) installed, enabled, and jailing SSH.
• ⬜ Firewall allowing only 22 (or your custom SSH port), 80, 443, with ufw-docker installed so those rules actually apply to Docker-published ports. Keep Dokploy's UI port (3000) closed to the public internet — put it behind Traefik on a domain (see Certificates) or behind a VPN (see the Tailscale guide).
• ⬜ A non-root user for day-to-day operations (log review, manual docker commands), in the docker group. Reserve root for provisioning and the SSH key Dokploy itself uses to manage the host.

Commands

Automatic security patches:

sudo apt update && sudo apt install -y unattended-upgrades apt-listchanges
sudo dpkg-reconfigure -plow unattended-upgrades
systemctl status unattended-upgrades

SSH — make sure your key is already in ~/.ssh/authorized_keys for the user you'll log in as before you touch this, then edit /etc/ssh/sshd_config:

PubkeyAuthentication yes
PasswordAuthentication no
PermitRootLogin no

Reload — don't close your current session until a new connection confirms it works:

sudo systemctl reload sshd

For a non-standard port, add Port 2222 (or your choice) to the same file, reload again, and update the firewall rule below to match.

Fail2Ban, jailing SSH:

sudo apt install -y fail2ban
sudo tee /etc/fail2ban/jail.local <<'EOF'
[sshd]
enabled = true
mode = aggressive
bantime = 1h
findtime = 10m
maxretry = 5
EOF
sudo systemctl enable --now fail2ban

Firewall:

sudo apt install -y ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

sudo wget -O /usr/local/bin/ufw-docker https://github.com/chaifeng/ufw-docker/raw/master/ufw-docker
sudo chmod +x /usr/local/bin/ufw-docker
sudo ufw-docker install
sudo systemctl restart ufw

Non-root operator user, added to the docker group so it doesn't need sudo for every container command:

sudo adduser deploy
sudo usermod -aG sudo,docker deploy

Copy your public key into /home/deploy/.ssh/authorized_keys before you rely on this account to log in.

3. Docker Engine

• ⬜ /etc/docker/daemon.json hardened — live-restore, no userland proxy, log rotation (see Commands below).
• ⬜ no-new-privileges applied — not a daemon-wide setting, it's set per service.
• ⬜ Never expose the Docker socket over TCP (dockerd -H tcp://..., ports 2375/2376) on any host Dokploy manages. Dokploy orchestrates remote servers over SSH, not the Docker remote API — a TCP socket isn't required for it to work, and one left open is unauthenticated root on the host.
• ⬜ Private registry credentials configured in Dokploy (see Registry) rather than docker login credentials sitting in shell history; use a registry token scoped to pull/push only what's needed.
• ⬜ Pin image tags in production (avoid :latest) so a redeploy doesn't silently pull an untested image.

Commands

/etc/docker/daemon.json — a sane baseline:

{
  "live-restore": true,
  "userland-proxy": false,
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

Restart the daemon to apply it — this briefly stops dockerd (not your containers, since live-restore keeps them running through the restart once it's set):

sudo systemctl restart docker

The log options cap json-file growth — without them, a noisy container can fill the disk.

no-new-privileges, per service, in the Docker Compose file or the app's Advanced settings:

security_opt:
  - no-new-privileges:true

4. Dokploy

• ⬜ 2FA or passkeys for every member with panel access — see Account Security. Passkeys are phishing-resistant and preferred for day-to-day sign-in.
• ⬜ SSO/OIDC or SAML if you have an IdP (Enterprise) — see SSO. Enterprise lets you force SSO for the organization, disabling password-based sign-in so every member authenticates through your IdP (and inherits whatever MFA policy you enforce there). Combine with SCIM Provisioning to auto-deprovision users the moment they leave your IdP, rather than relying on someone remembering to remove them from Dokploy.
• ⬜ Least-privilege roles. Use the built-in Member permissions (see Permissions) or, on Enterprise, Custom Roles scoped per project/environment. Don't hand out Admin by default.
• ⬜ Secrets Providers instead of raw values in env vars — see Secrets Providers. Values are fetched at deploy time and never stored in the Dokploy database; your vault stays the source of truth, and rotation there takes effect on the next deploy.
• ⬜ API/CLI tokens — restrict the Access to API/CLI permission to who actually needs it. Tokens are scoped to your organization and can be created with an expiration — always set one instead of leaving a token to stand forever, issue a separate token per integration (CI, webhook, script) so you can revoke one without breaking the others, and regenerate immediately on offboarding or suspected exposure.
• ⬜ Audit Logs (Enterprise) covering logins, role changes, deployments, and infrastructure changes — see Audit Logs. This is usually the single most-requested control in a security review.

5. Traefik & Networking

• ⬜ TLS is automatic for domains managed through Dokploy's Applications flow — Let's Encrypt via certResolver, with an HTTP router that redirects to HTTPS by default. Docker Compose domains use Traefik labels instead and need the same redirect added explicitly — see Domains and Docker Compose Domains.
• ⬜ HSTS, applied via a custom middleware — not automatic today (see Config snippets below).
• ⬜ Keep the Traefik dashboard off — it isn't exposed by a default Dokploy install, and it should stay that way unless it's behind auth and off the public network.
• ⬜ Rate limiting on public-facing services — no UI toggle for this yet, so it also goes through a custom middleware.
• ⬜ Isolate networks per project. By default, apps share dokploy-network. For Docker Compose stacks, enable Isolated Deployments so each stack gets its own network and containers can't reach services in unrelated projects by name.
• ⬜ No Docker socket over TCP anywhere in the cluster (see Section 3) — this is as much a networking control as a Docker one.

Config snippets

Dokploy's Applications flow writes a domain config like the one shown in Domains — a routers + services block per domain, editable from the app's Advanced → Traefik File System tab. Add a headers middleware for HSTS and reference it from the websecure router's middlewares list:

http:
  middlewares:
    secure-headers:
      headers:
        stsSeconds: 31536000
        stsIncludeSubdomains: true
        stsPreload: true
  routers:
    dokploy-app-name-router-websecure-1:
      middlewares:
        - secure-headers
      # ...rest of the router config Dokploy already generated

Same file, a ratelimit middleware:

http:
  middlewares:
    rate-limit:
      rateLimit:
        average: 100
        burst: 50
  routers:
    dokploy-app-name-router-websecure-1:
      middlewares:
        - rate-limit

average is requests/second sustained per source, burst is the short spike allowed above it — tune both to your traffic pattern before relying on them.

6. Database

• ⬜ Use Internal Credentials for anything an application in the same network needs — never enable External Credentials (a published port) unless there's a real requirement, and if there is, restrict it with a firewall rule or put it behind a VPN rather than leaving it open to the internet. See Database Connection.
• ⬜ Backups to an S3 destination — see Database Backups. Dokploy doesn't encrypt the backup archive itself, so enable encryption at rest on the bucket (SSE-S3 or SSE-KMS) and scope the destination credentials to that bucket only.
• ⬜ Test restores. A backup you haven't restored isn't a backup — see Restore (or Volume Backups for volumes) and schedule a periodic restore drill. That's the evidence that actually matters, not the backup schedule itself.

7. Observability

• ⬜ Audit Logs (Enterprise) as your primary who-did-what trail — see Audit Logs.
• ⬜ External log shipping. Dokploy's built-in Monitoring is currently a Cloud-only feature — for self-hosted, ship container and host logs (Docker's log driver, syslog, or a log shipper) to something outside the box you're monitoring, so a compromised host can't erase its own trail.
• ⬜ Alert on auth anomalies — repeated Fail2Ban bans, spikes in Traefik 401/403s, failed Dokploy logins. Wire up a notification provider (Slack, email, webhook) for at least deployment failures and server thresholds as a baseline signal.

8. Final Checklist

9. Compliance Mapping

Illustrative mapping to common SOC 2 Trust Services Criteria and ISO/IEC 27001:2022 Annex A control families — use it as a starting point and align the exact control IDs with your own GRC tooling.