Guidelines for Deploying with AI Agents
Last verified 6 Nov 2026
AI agents can deploy to DigitalOcean through the MCP servers, the API, or doctl. Use these guidelines to validate app specs, control database access, troubleshoot deployments, wait for resources, and delete test resources.
Check Cost and Validate App Specs Before You Create
Send an App Platform app spec to the propose app spec endpoint before you create the app. The endpoint validates the spec without creating resources and returns the estimated monthly cost in app_cost and whether the app qualifies as static in app_is_static. The endpoint rejects invalid specs before creation.
The App Platform free tier covers up to three apps per team that contain only static site components. Additional apps with static site components and any service, worker, or job components are billed at the plan rates. Function components are billed for usage beyond the Functions free allowance. Apps are billed by the second with a one-minute minimum, and databases are billed by the hour with a one-hour minimum, so short-lived test resources still incur a small charge.
Match App Regions to Database and VPC Datacenters
App Platform regions, such as nyc, map to a single datacenter for VPC connections, such as nyc1. An app can only connect privately to VPC networks in that datacenter. When an agent creates a database or Droplet for an app to reach over the private network, create it in the datacenter from the mapping in How to Enable App Platform VPC. Otherwise, the propose endpoint rejects the spec with an error such as Apps in region nyc can only connect to VPCs in nyc1 (selected VPC is in nyc3).
Restrict Database Access After You Create a Cluster
Add trusted sources after the cluster is online to restrict inbound connections, as described in How to Secure PostgreSQL Managed Database Clusters. When you attach a cluster that already has trusted sources to an App Platform app, App Platform adds the app as a trusted source automatically. See How to Manage Databases in App Platform.
Debug Failed App Deployments
App Platform records build, deploy, and runtime logs for each deployment. Match the log type to where the deployment failed:
- Build logs: Record the commands, errors, and warnings from the build process.
- Deploy logs: Record errors and warnings from the deployment process.
- Runtime logs: Record messages and errors emitted by app components while they run.
The logs endpoint returns URLs rather than log text. The live_url may use either https:// or wss:// and streams logs as they become available.
To recover from a bad deployment without rebuilding a full spec, list the app’s deployments and roll back to one of the ten most recent successful deployments.
Wait for Resources to Be Ready
For Droplets, follow Wait for the Droplet’s IP Address before connecting.
The create database response initially reports the cluster’s status as creating. Poll the retrieve database cluster endpoint until its status is online before connecting.
Delete Test Resources Completely
Record the names and IDs of every resource an agent creates. Apply a common tag, such as agent-test, to resource types that support tags. Then delete each resource type:
- App Platform apps: Destroy each app. Attached managed database clusters continue running and billing after you destroy an app.
- Managed database clusters: Destroy each attached cluster separately, for example by following How to Destroy PostgreSQL Database Clusters.
- Functions namespaces: Destroy each namespace, which also destroys its projects and functions.
- Droplets, firewalls, and SSH keys: Destroy each Droplet, destroy each firewall, and remove each SSH key from the team.
After deleting the resources, list each resource type and confirm the recorded names and IDs no longer exist. To confirm that charges have stopped, check the Billing page.