DigitalOcean
Connect a DigitalOcean team and run services on App Platform with Managed PostgreSQL, MySQL and Valkey.
Loomplane runs your services on DigitalOcean App Platform and gives them Managed PostgreSQL, MySQL and Valkey databases. App Platform builds each service from your repository, so you don't need a registry or a builder of your own.
Connect DigitalOcean
In DigitalOcean, open API, then Tokens, and create a personal access token with read and write access. A custom-scoped token needs app, database and account:read.
Under Settings, then GitHub, give DigitalOcean access to the repositories you'll deploy. App Platform clones them through that connection. Loomplane never hands it your code.
In Loomplane, open Integrations, choose DigitalOcean and paste the token.
Loomplane asks DigitalOcean whose token it is before it keeps it. A token belongs to one team, and that team is where every app and database is made. A token from a locked account is refused.
Use it in a manifest
version: 1
defaults:
provider: digitalocean
region: ams
services:
web:
source: apps/web
needs: [api]
api:
source: services/api
needs: [db]
resources:
db:
kind: postgres
version: "16"The regions are App Platform's: nyc, sfo, tor, atl, ams, fra, lon, blr, sgp and syd. Leave region out and you get nyc.
Each service in each environment becomes an App Platform app of its own, named after the service, the environment and the project, with deploy on push turned off. A service with a Dockerfile builds from it. Anything else goes through App Platform's buildpacks. Workers run as App Platform workers and static sites as static sites. size picks the smallest instance that fits, from apps-s-1vcpu-0.5gb up to apps-d-8vcpu-32gb, and scale.min sets how many instances run. Secret variables go in as App Platform secrets.
Which commit runs
Every other target here deploys the exact commit a plan approved. App Platform can't, because it always builds the newest commit of a branch and gives you no way to ask for a particular one. So Loomplane checks instead.
It points the app at the branch your project reads, starts the deployment itself, and watches the commit App Platform reports for every component. If that's the approved commit, the deployment goes ahead. If someone pushed to the branch after you approved the plan, Loomplane cancels the deployment before it goes live and the step fails with both commits in the message. In the rare case a wrong build gets live before the check sees it, Loomplane rolls the app back to what ran before, or deletes the app if nothing approved ever ran there.
So don't push to a branch while a plan for it waits for approval. If your repository's default branch isn't main, set the branch on the project's repository in Loomplane, because a repository left on its default branch is built from main. To deploy another branch for a while, analyze it with Another branch: a plan builds the branch its analysis read.
A brand-new app's ondigitalocean.app address takes a few minutes to appear in DNS after App Platform says it's live. Loomplane waits for it in public DNS for up to ten minutes before it checks that the service answers. If it still isn't there, the step says the app is deployed, and retrying checks again.
Databases
| Manifest kind | Made on DigitalOcean | Versions |
|---|---|---|
postgres | Managed PostgreSQL | 17, 16, 15 |
mysql | Managed MySQL | 8 |
redis | Managed Valkey, which speaks the Redis protocol | DigitalOcean's current one |
Each is a single db-s-1vcpu-1gb node in the datacenter that matches the region: nyc gets nyc3, ams gets ams3, fra gets fra1, and so on. You can name a datacenter outright, such as nyc1, as a resource's region. Services that need a database get its connection string as a secret, with TLS required. Loomplane doesn't set trusted sources, so add them in DigitalOcean if you want only your apps to reach it.
Removing a database from the manifest deletes it with its data, so take a backup first if you need one.
Limits
A private service is only reachable from inside its own App Platform app, and each service here gets its own app, so nothing can call one. The planner says so and asks you to make it public. Build logs stay on the app's Activity tab, and Loomplane shows the deployment's progress. App Platform custom domain attachment is a separate capability that Loomplane doesn't configure.
Droplets and DNS
You can also provision managed Droplets in an organization Cloud, adopt a pinned SSH/Docker host, and place services through server pools. That uses the server runtime, and your App Platform manifests keep using the managed runtime. Your own servers has the commands.
DigitalOcean's compute and DNS capabilities are checked independently. Your App Platform token scopes don't establish Droplet or DNS permissions, so an operation without the permission it needs fails before any new effects. For a managed DNS zone you can use a different account than the one for compute.
Fixture-backed provider and ACME checks don't qualify your DigitalOcean account, DNS propagation or public certificate issuance. Verify those with your own authorized live scope before a production move.