Move from AWS App Runner

AWS App Runner no longer accepts new customers, and AWS doesn’t plan new features for it (AWS App Runner availability change). Existing services keep running, so you can move when it suits you.

ScaleBop runs your app as a container on Amazon ECS with Fargate, behind a load balancer and CloudFront, in your own AWS account. It builds from your GitHub repository with a GitHub Actions workflow and saves the setup as AWS CDK in the repo. This guide moves one App Runner service across, with App Runner serving until the new app is ready.

1. Note down your App Runner settings

In the App Runner console, open the service and write down:

• Source: the GitHub repository, branch and source directory, or the container image if the service deploys an image.
• Build and start commands, from the service settings or apprunner.yaml.
• Port the app listens on.
• Environment variables, and which of them are secrets (App Runner references these from Secrets Manager or Parameter Store).
• Health check path, if you set one.
• Custom domain, if you use one.
• Networking: whether the service uses a VPC connector to reach a private database or other resources.

2. Make sure ScaleBop can build it

ScaleBop deploys from a GitHub repository.

• Node.js and Python apps (Next.js, Express, FastAPI, Flask, Django and others) need no Dockerfile: ScaleBop writes one if the repo doesn’t have it.
• Other languages need a working Dockerfile in the repo. App Runner’s managed runtimes built your image without one, so add a Dockerfile that runs the same build and start commands. See Bring your own Dockerfile.
• Image-only services whose image is built elsewhere: put the Dockerfile in the GitHub repository ScaleBop deploys from.

The app must listen on the port in the PORT environment variable, on 0.0.0.0. App Runner apps usually already do.

3. Create the project

1. Sign up, connect GitHub and pick the repository.
2. Connect your AWS account (Connect AWS). It can be the same account App Runner runs in.
3. On the plan step, confirm the container port and health check path from step 1.

4. Bring your environment variables across

Add each variable on the project’s Configuration step, and mark secrets as secrets: they’re stored in AWS Secrets Manager and injected when the container starts, never written into the repository. See Environment variables.

ScaleBop also sets a few variables for you, such as PORT and FRONTEND_URL. Your app should read the request scheme from CloudFront-Forwarded-Proto, because CloudFront talks to the load balancer over plain HTTP.

5. Check the database connection

App Runner doesn’t host databases, so yours stays where it is. Set DATABASE_URL on the Configuration step (Database).

If App Runner reached your database through a VPC connector (a private RDS instance, for example), the ScaleBop container doesn’t run in that VPC and won’t reach it as it is. Before you switch, either allow connections with TLS and a password from outside the VPC, or move the data to a database ScaleBop creates in the same account (Create Postgres in your AWS account). A task’s outbound IP changes when it’s replaced, so an IP allowlist won’t hold.

6. Deploy and test

Merge the setup pull request ScaleBop opens. ScaleBop starts the first deploy, and the launch only counts once the app answers its health check.

Test the app on the HTTPS address ScaleBop shows (a cloudfront.net URL) before touching DNS. CloudFront waits up to 60 seconds for a response, so a request App Runner allowed to run longer needs to move to a background job.

7. Move your domain

1. Add the domain on the project’s Custom domains screen and choose how DNS is managed (Custom domains).
2. Point the hostname at the CloudFront address ScaleBop shows. Until you do, App Runner keeps serving it.
3. Keep App Runner running for a day or two after the switch, so DNS caches expire and you can switch back if you need to.

8. Remove the App Runner service

Once traffic has moved and the new app has run cleanly for a while, remove the custom domain from the App Runner service, then delete the service in the App Runner console. Delete any images in Amazon ECR and IAM roles you created only for App Runner.

Differences to plan for

• Scaling: ScaleBop runs one container. App Runner scaled for you; with ScaleBop, scaling is a change in the generated CDK.
• Deploys: commits don’t go live until you Ship changes, unless you turn on Auto-ship (Deploying).
• Request time: CloudFront waits up to 60 seconds for the container to respond.