How to Migrate from DigitalOcean App Platform to AWS

DigitalOcean App Platform describes an app in one spec: services that take HTTP traffic, workers, jobs that run before or after a deploy or on a schedule, and attached Managed Databases, with Spaces for files. Teams move to AWS for compliance, for an enterprise customer that requires it, for AWS credits, or for services App Platform does not offer. The move is mostly translation, since each component has an AWS counterpart, plus a data migration for Postgres and Spaces.

This guide maps an App Platform app to AWS component by component, covers the data move and DNS cutover, and shows two ways to build the AWS side: declare the resources in application code with Encore, or rebuild them with ECS and Terraform by hand.

Start with the app spec

The app spec is the inventory of everything that has to move, so export it before changing anything:

Each section of the spec maps to AWS like this:

Scheduled jobs in the spec carry a time_zone, while Encore cron schedules run in UTC, so convert each schedule when you move it. Bindable variables such as the App Platform database URL placeholder disappear, because the connection details on AWS come from the new database.

Provision the AWS side from application code

Encore combines an open source infrastructure SDK with a platform that provisions and deploys into your own AWS or GCP account. For TypeScript and Go it is a backend framework with built-in infrastructure: the database, buckets, workers and scheduled jobs from the app spec are declared in the code that uses them, and Encore provisions the matching AWS resources on deploy.

Declare what the spec described

The database, the Spaces bucket, the worker and the scheduled job from a typical spec become declarations in one service:

// app/resources.ts
import { CronJob } from "encore.dev/cron";
import { api } from "encore.dev/api";
import { Subscription, Topic } from "encore.dev/pubsub";
import { SQLDatabase } from "encore.dev/storage/sqldb";
import { Bucket } from "encore.dev/storage/objects";

// Replaces the App Platform managed Postgres cluster. RDS on AWS.
export const db = new SQLDatabase("app", { migrations: "./migrations" });

// Replaces a Spaces bucket. S3 on AWS.
export const uploads = new Bucket("uploads", { versioned: false });

// Replaces a worker component that polled for work. SNS and SQS on AWS.
interface EmailJob {
  userId: string;
  template: string;
}
export const emails = new Topic<EmailJob>("emails", { deliveryGuarantee: "at-least-once" });

const _ = new Subscription(emails, "send-email", {
  handler: async (job) => {
    // send the email
  },
});

// Replaces a scheduled task. Run by the Encore platform, in UTC.
export const cleanup = api({}, async (): Promise<void> => {
  await db.exec`DELETE FROM sessions WHERE expires_at < now()`;
});

const nightly = new CronJob("cleanup", { title: "Delete expired sessions", schedule: "0 3 * * *", endpoint: cleanup });

The PRE_DEPLOY migration job is replaced by the migrations directory on the database, which Encore applies on every deploy. Secret variables from the spec move to secrets set with encore secret set --type prod. Non-secret variables have no direct equivalent, so values that are the same everywhere become constants in code. encore run starts Postgres locally, along with the queue and a local bucket, so the app runs on a laptop before anything is deployed.

Deploy next to App Platform

Connect your AWS account in the Encore dashboard under Integrations > Connect Cloud, as described in Connect your cloud account, create an environment on AWS and run git push encore. Encore provisions a VPC, Fargate behind an Application Load Balancer, RDS for PostgreSQL, the S3 bucket, an SNS topic and SQS queue with a dead-letter queue for the subscription, and Secrets Manager entries, and it provisions an IAM role for the service, as listed in the AWS infrastructure docs, and cron jobs run from the Encore platform with no extra AWS resources. The App Platform app keeps serving traffic while the AWS environment comes up.

The PaaS migration guide covers the same mapping for other platforms.

Best fit: teams whose App Platform spec is mostly application resources (services, workers, Postgres, Spaces and scheduled jobs) and who want those declared in the same TypeScript or Go code on AWS.

AWS by hand with ECS and Terraform

Without Encore, each spec section becomes Terraform or CDK, starting with services as ECS services on Fargate behind an Application Load Balancer, built from the same Dockerfile and pushed to ECR. Workers are ECS services without a load balancer that poll SQS, which means adding a queue to code that previously polled a database or Redis. PRE_DEPLOY jobs become a one-off ECS task that the pipeline runs before updating the service, and SCHEDULED jobs become EventBridge Scheduler schedules that start an ECS task. Managed Postgres becomes RDS in private subnets, Spaces becomes an S3 bucket with a policy for each task role, and secrets go to Secrets Manager referenced from the task definitions. Budget for the VPC, NAT gateways, security groups and IAM roles that App Platform handled implicitly.

Best fit: teams with an infrastructure engineer and an existing Terraform codebase who want every AWS setting in their own modules.

Move the data

Managed Postgres to RDS

If the managed database has trusted sources configured, add the IP of the machine doing the transfer, then dump over TLS. The host, port, database and user are under the database's Connection Details, on port 25060. Put the password in a mode 600 .pgpass file (hostname:port:database:username:password) so pg_dump and pg_restore never receive it as an argument, and create the dump with a private umask:

With Encore, the target is either the database Encore created, where you restore data only into the schema your migrations built, using encore db conn-uri app --env=prod --admin for the connection string, or an RDS instance you restored yourself and attach with Import Existing Database. Check the major version and extensions first, and run ANALYZE after the restore.

Spaces to S3

Spaces is S3-compatible, so rclone can copy between them with two remotes, one with the Spaces endpoint such as fra1.digitaloceanspaces.com and one for S3:

Code that built URLs from the Spaces CDN hostname needs the new bucket's URL, or signed URLs from the bucket API.

The cutover

1. Deploy the AWS environment and test it on its generated URL.
2. Lower the TTL on the app's DNS records a day ahead.
3. Stop writes on App Platform by scaling workers to zero and switching the app to a maintenance page or a read-only mode in code.
4. Take the final Postgres dump and Spaces sync, restore and verify row counts.
5. Add the custom domain to the AWS environment and point DNS at it.
6. Keep the App Platform app and database for a few days in case you need to roll back, then delete them.

How to choose

If an infrastructure team already owns AWS modules, map each spec section into ECS, RDS, S3 and EventBridge Scheduler with Terraform or CDK. If most of the spec is application resources you want declared next to the code that uses them, with the same setup on a laptop, Encore provisions those in your AWS account from TypeScript or Go.

Related guides

• DigitalOcean App Platform alternatives
• DigitalOcean vs AWS
• How to migrate Heroku Postgres to RDS
• How to migrate a Node.js app from Render to AWS
• Cron jobs on AWS without Terraform