AWS App Runner shuts down in 2026: migrate to ECS Fargate

If your app runs on AWS App Runner, plan to be off it before the service is retired in 2026. The clean landing spot for most containerized web apps is ECS on Fargate behind an Application Load Balancer: you keep serverless-style container scaling, you own the networking, and you gain the health-check and traffic-shifting primitives App Runner hid from you. The migration is mostly mechanical for stateless HTTP services and genuinely harder for anything holding state. This post walks the path honestly, and shows where a Vylara agent can do the tedious parts for you inside your own AWS account.

Why Fargate, and why not just re-Heroku yourself #

App Runner sold a specific promise: hand it a container or a repo, get back a URL, forget about load balancers and target groups. That convenience is exactly what disappears when the service goes away. The nearest AWS-native equivalent that gives you the same ’push and it scales’ feel without renting a whole PaaS is ECS Fargate. You define a task (CPU, memory, container image, port), an ECS service to keep N copies healthy, and an ALB to route traffic to them. Fargate bills per second of vCPU and memory — roughly $0.04048 per vCPU-hour and $0.004445 per GB-hour in us-east-1 — so a small 0.25 vCPU / 0.5 GB service costs on the order of $9–11/mo before the ALB, which adds about $16–18/mo minimum. That ALB cost is real and worth budgeting for; it’s one of the line items we called out in the anatomy of an AWS bill shock.

Comparing Fargate against plain Lambda or self-managed EC2 is a legitimate decision, not a foregone conclusion. If your traffic is spiky and your requests are short, functions may be cheaper; if it’s steady, containers usually win. We laid out that trade-off in serverless vs managed containers, and the short version is: for a long-running HTTP service that App Runner was already hosting, Fargate is the least-surprising move.

What actually changes in the migration #

App Runner gave you a managed URL, automatic HTTPS, and health checks against a path you configured. On Fargate you rebuild those explicitly. Your container image is likely fine as-is — Fargate runs the same OCI image App Runner did. What you add is a task definition, a service, a target group with a health-check path (typically GET /health returning HTTP 200), listener rules on the ALB, and security groups scoped so only the load balancer can reach your tasks. That last point matters: security groups written by hand tend to be looser than they need to be, and we’ve written before about how generating security groups from code produces tighter rulesets than most people author under deadline pressure.

A minimal Fargate task definition is smaller than people expect. The essential shape looks like this:

{
  "family": "web",
  "requiresCompatibilities": ["FARGATE"],
  "networkMode": "awsvpc",
  "cpu": "256",
  "memory": "512",
  "containerDefinitions": [
    {
      "name": "app",
      "image": "<account>.dkr.ecr.<region>.amazonaws.com/web:v1.3",
      "portMappings": [{ "containerPort": 8080 }],
      "healthCheck": {
        "command": ["CMD-SHELL", "curl -f http://localhost:8080/health || exit 1"],
        "interval": 30,
        "timeout": 5,
        "retries": 3
      }
    }
  ]
}

Your environment variables are the other migration surface. App Runner let you set them in its console; on Fargate the durable pattern is to keep secrets out of the task definition and inject them at deploy time. This is a good moment to stop pasting connection strings into a console and move them into AWS Secrets Manager. If your keys are currently scattered across Slack threads and .env files, your secrets need an exit plan before you cut over, not after.

Stateless is easy; stateful is where you slow down #

Be honest with yourself about what you’re moving. A stateless HTTP service — request in, response out, no local disk — is a same-day migration: build the image, define the task, wire the ALB, cut traffic. A service that owns a database, a Redis cache, or a queue needs those backing resources provisioned and connected first, and any data migration adds real risk and downtime windows. If App Runner was fronting an RDS database, your cutover plan has to account for connection limits and backups; we cover the small-team version of that in an RDS backup strategy for teams without a DBA.

How Vylara does this in your account #

You install the Vylara GitHub App and point it at the repository that’s currently on App Runner. The agent clones the repo, detects the stack, and identifies what the app needs — PostgreSQL, Redis, S3, a queue — reading the same dependency signals it always does (prisma implies a database, ioredis implies a cache). It then opens a pull request from vylara-ai[bot] containing the Dockerfile, CI pipeline, and deployment configs, which you review in a diff view with plain-language explanations. Nothing lands in your repo without your approval, and nothing is created in AWS on merge. Merging updates the code; the first deploy provisions the Fargate service, target group, and any managed resources in your own AWS account via a blue/green rollout, so the new version comes up on a standby group and only takes traffic after health checks pass.

After launch, the connection URL is persisted and shown on your dashboard, and the in-app infrastructure chat can read your service logs and metrics to help diagnose a 502 or a failed health check — proposing fixes that you approve inline rather than running them silently. The honest caveat: AI-generated sizing is a guess until real traffic tunes it, and the agent’s plan is a starting point you should read, not rubber-stamp. That review gate is the point, not a formality. For the broader picture of running AWS this way with a small team, start from deploy without a DevOps team.

The practical takeaway: don’t wait for the retirement date to force a rushed cutover. Move stateless services first while you have slack, get your secrets into Secrets Manager, and treat stateful services as their own project with a rehearsed data migration and a rollback plan. Fargate behind an ALB is boring, well-documented, and yours — which is exactly what you want when a managed service you depended on gets sunset.