What problem will this feature address?
I'm always frustrated when adding a server to Dokploy requires provisioning the VM manually first — through the provider's console, CLI, or an external tool like Terraform — and only then pasting the IP and SSH key into Dokploy to register it. There's no way to create the underlying infrastructure from within Dokploy itself, so the "multi-server from day one" story still needs a separate tool/workflow before Dokploy even enters the picture.
Describe the solution you'd like
Add a "Cloud Providers" section under Settings, following the same pattern as the existing Secrets Providers / DNS Providers: you connect a provider account (API token/credentials, with a Test Connection button like the others), and can then create a new server directly from Dokploy — pick size/region/image, Dokploy provisions the instance via the provider's API, waits for it to become reachable, and runs the existing server bootstrap flow (Docker, Traefik, monitoring agent) automatically. No manual SSH copy-paste for the initial setup.
I'd like to start with DigitalOcean only (simplest API surface — a single droplet creation call with ssh_keys attached), then follow up with AWS EC2 and OVH in separate PRs once the pattern is validated by maintainers.
Describe alternatives you've considered
Provisioning the server outside Dokploy with Terraform or a provider's own CLI, then registering it via the existing server.create API once it has an IP. This works today, but it's a separate tool and workflow instead of a first-class Dokploy feature, and it doesn't benefit from being wired into the same UI/permissions model as everything else.
A fully generic "any provider via Terraform" approach was also considered, but it's a much bigger scope and harder to review/maintain than dedicated provider integrations following the existing pattern (Secrets/DNS Providers).
Additional context
Planned approach mirrors the existing Secrets Providers module:
- packages/server/src/db/schema/cloud-provider.ts
- packages/server/src/services/cloud-provider.ts (CRUD + testConnection + createServer)
- apps/dokploy/server/api/routers/cloud-provider.ts
- Settings UI under components/dashboard/settings/cloud-provider/
Open questions I'd want input on before starting:
- Should server creation be async (queued job + status polling), or is a blocking request acceptable for v1?
- Any preference on which provider should land first, or is OVH fine as the initial scope?
- Should this live behind the same permission-resource pattern as vaultProvider, or its own dedicated permission?
Will you send a PR to implement it?
Yes
What problem will this feature address?
I'm always frustrated when adding a server to Dokploy requires provisioning the VM manually first — through the provider's console, CLI, or an external tool like Terraform — and only then pasting the IP and SSH key into Dokploy to register it. There's no way to create the underlying infrastructure from within Dokploy itself, so the "multi-server from day one" story still needs a separate tool/workflow before Dokploy even enters the picture.
Describe the solution you'd like
Add a "Cloud Providers" section under Settings, following the same pattern as the existing Secrets Providers / DNS Providers: you connect a provider account (API token/credentials, with a Test Connection button like the others), and can then create a new server directly from Dokploy — pick size/region/image, Dokploy provisions the instance via the provider's API, waits for it to become reachable, and runs the existing server bootstrap flow (Docker, Traefik, monitoring agent) automatically. No manual SSH copy-paste for the initial setup.
I'd like to start with DigitalOcean only (simplest API surface — a single droplet creation call with ssh_keys attached), then follow up with AWS EC2 and OVH in separate PRs once the pattern is validated by maintainers.
Describe alternatives you've considered
Provisioning the server outside Dokploy with Terraform or a provider's own CLI, then registering it via the existing server.create API once it has an IP. This works today, but it's a separate tool and workflow instead of a first-class Dokploy feature, and it doesn't benefit from being wired into the same UI/permissions model as everything else.
A fully generic "any provider via Terraform" approach was also considered, but it's a much bigger scope and harder to review/maintain than dedicated provider integrations following the existing pattern (Secrets/DNS Providers).
Additional context
Planned approach mirrors the existing Secrets Providers module:
Open questions I'd want input on before starting:
Will you send a PR to implement it?
Yes