Feature: Cloud Providers — auto-provision servers (OVH, AWS, DigitalOcean, etc)

Open
  • Is something wrong?
#5,500 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
45/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
aws, terraform, typescript
Domain
backend-api-design, cloud, devops, infrastructure

Research direction

Start by reading the existing Secrets Providers and DNS Providers implementations, then inspect the planned files: packages/server/src/db/schema/cloud-provider.ts, packages/server/src/services/cloud-provider.ts, apps/dokploy/server/api/routers/cloud-provider.ts, and the settings UI directory. Done means a DigitalOcean-first provider can connect, create a server with the selected size, region, image, and SSH key, and invoke the existing bootstrap flow; the async behavior and permission model still need maintainer input.

Written by the indexing model from the issue text.

Description

enhancement
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:

  1. Should server creation be async (queued job + status polling), or is a blocking request acceptable for v1?
  2. Any preference on which provider should land first, or is OVH fine as the initial scope?
  3. 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

Dominant language
TypeScript
Stars
38.2k
Forks
3.1k
Avg merge
2d 7h
Merged PRs (30d)
69

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Dokploy/dokploy

All issues in Dokploy/dokploy

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.