Security Roadmap Discussion: Hardening Self-Hosted Dokploy for Production Use

[julianwitzel]

Hi team,

First off — huge thanks for Dokploy. We've been running it for our SaaS infrastructure (Hetzner + Docker Swarm) and it's been a fantastic experience. The DX is genuinely excellent.

I wanted to start a discussion about Dokploy's security posture as it scales toward production-grade and enterprise use cases. Some of these features would unlock adoption in regulated industries and reduce real risk for all users — not just nice-to-haves.

This isn't a list of complaints; it's a roadmap proposal for community discussion.

Core Security Gaps

1. Encryption-at-Rest for Secrets in Database

Current: All environment variables (including DB passwords, API keys, OAuth secrets) are stored as plaintext in Dokploy's Postgres database.

Risk: Anyone with DB access (including via SSH to the controller) sees all secrets across all projects in plaintext.

Proposed: Symmetric encryption (AES-256-GCM) with master key from controller environment. Standard pattern, moderate implementation effort.

Related: #2817

2. External Secrets Manager Integration

Current: Secrets must be entered directly into Dokploy.

Risk: No audit trail of secret access, no automated rotation, no separation of concerns between deployment platform and secret store.

Proposed: Provider integration following the existing S3 Destinations pattern — connect Vault / AWS Secrets Manager / Doppler / Bitwarden Secrets / Infisical, then reference secrets via {{vault.DB_PASSWORD}} syntax.

Related: #3821

3. Encrypted Backups

Current: Database backups are uploaded as plain SQL dumps to S3 destinations.

Risk: Compromised S3 credentials = full data exposure. This is especially concerning for ransomware scenarios where attackers exfiltrate backups before encrypting production.

Proposed: Pre-upload encryption hook using age or GPG with a configurable public key. Private key never lives on the server, only with the user (e.g., 1Password, hardware token). Even if S3 credentials leak, backups remain unreadable.

4. Audit Trail in Open Source Tier

Current: Audit Trail is Enterprise-only.

Risk: Without audit logs, there's no forensic capability when something goes wrong. This is a compliance baseline, not a premium feature, in 2026.

Proposed: Basic audit trail (login events, deployments, env-var changes, backup operations) in OSS. Advanced features (long retention, SIEM integration, export, compliance reports) can remain Enterprise.

5. SSO in Open Source Tier

Current: SSO is Enterprise-only.

Risk: Password authentication has been the weakest link for over a decade. Not having SSO available means every team has to manage password hygiene manually.

Proposed: Basic OIDC SSO (Google / GitHub / Microsoft) in OSS. Custom SAML, SCIM, JIT provisioning, and identity federation can remain Enterprise.

6. Enforceable 2FA

Current: 2FA can be enabled per-user but cannot be enforced for all workspace members.

Risk: A single workspace member without 2FA is the weakest link.

Proposed: Workspace-level "Require 2FA for all members" toggle. Members without 2FA get prompted on next login.

7. Image Vulnerability Scanning

Current: Images are pulled and deployed without security checks.

Risk: Supply chain attacks via compromised npm/pypi packages or base images go undetected.

Proposed: Optional Trivy or Grype integration that scans images on pull. Configurable: warn, block deploy on critical CVEs, or just log. Could integrate with the existing deployment flow.

8. Network Isolation by Default

Current: All services within a project share the same Docker network. Frontend can theoretically connect directly to the database.

Risk: Lateral movement after a single service compromise.

Proposed: Default-deny inter-service communication, explicit "allow" rules for inter-service connections. Similar pattern to Kubernetes NetworkPolicies.

9. Rate Limiting on Authentication

Current: No rate limiting on Dokploy login endpoints (as far as I can tell).

Risk: Brute force attacks against weaker passwords.

Proposed: Standard rate limits + IP block after N failed attempts. Trivial to implement, basic hygiene.

10. Secret Rotation Workflow

Current: Rotating a database password requires manual coordination — change in DB, update env var, redeploy.

Risk: High friction means rotation rarely happens. Compromised credentials remain valid longer than they should.

Proposed: Built-in rotation workflow that atomically generates new credentials, updates the database, updates app env vars, and rolls deployments.

11. Security Headers in Default Traefik Config

Current: Apps deployed via Dokploy don't get security headers by default.

Risk: Missing CSP, HSTS, X-Frame-Options means vulnerabilities like clickjacking and mixed content go unprevented.

Proposed: Sensible default security headers in the Traefik configuration, with per-app overrides.

Priority Suggestion

If I were prioritizing for maximum risk reduction with reasonable effort, my top 3 would be:

1. Encryption-at-rest for secrets (Feature request: multi node support #1) — highest impact, well-known pattern
2. Enforceable 2FA (Docker compose file #6) — basic hygiene, low effort
3. Encrypted backups (Queries regarding licenseing and advertising as open source #3) — solves the "compromised S3 keys = total data loss" scenario

Why This Matters

Dokploy is positioned as a serious alternative to Vercel / Heroku / Railway for self-hosted deployments. To compete in that space — especially for B2B SaaS with compliance requirements (SOC2, ISO 27001, GDPR) — these features become table stakes, not differentiators.

I'd be happy to contribute to any of these if there's interest from maintainers. Some (encryption-at-rest, rate limiting, 2FA enforcement) are well-scoped enough that a community PR could land relatively quickly.

Curious to hear from other users: which of these would be most valuable for your setup? And from maintainers: what's already on the roadmap, what's not, and what would you accept community PRs for?

Thanks!