Heroku-Style Platforms That Deploy to Your Own AWS Account (2026)

What made Heroku work was not the dyno. It was that the shape of an app, a web process, a worker, a scheduler and a Postgres add-on, mapped straight to a deploy, and nobody on the team ran servers. Moving into your own AWS account keeps the bill and the data where you want them, and it brings back the question of who runs what.

Each platform below answers it differently. Encore reads the app's shape from its code, most of the others from a dashboard or config file, and several put an EKS cluster in your account that the platform manages and AWS bills you for. The right one is the platform whose model matches your app, at an operational cost you are happy to carry.

What a Heroku-style platform in your AWS account needs:

• Web, worker and scheduled processes from one repository.
• A managed database in the same account.
• Deploys on git push, with preview environments for pull requests.
• Resources that stay yours if you stop using the platform.

Platforms at a glance

Encore: web, worker and scheduler from the code, without a cluster to run

Encore is an open source infrastructure SDK for TypeScript and Go that declares infrastructure in the application code, and deploys to your own AWS account on git push. The three Heroku process types, web, worker and scheduler, are part of the same code, so the platform reads the app's shape instead of a Procfile.

import { api } from "encore.dev/api";
import { Topic, Subscription } from "encore.dev/pubsub";
import { CronJob } from "encore.dev/cron";
import log from "encore.dev/log";

interface Job {
  id: string;
}

const jobs = new Topic<Job>("jobs", { deliveryGuarantee: "at-least-once" });

// Web: an HTTP endpoint behind the load balancer.
export const enqueue = api(
  { expose: true, method: "POST", path: "/jobs" },
  async (req: Job): Promise<Job> => {
    await jobs.publish(req);
    return req;
  },
);

const done = new Set<string>(); // Use a table with a unique key in production.

// Worker: an SQS subscription on AWS.
const _worker = new Subscription(jobs, "process", {
  handler: async (job) => {
    if (done.has(job.id)) return; // At-least-once delivery.
    done.add(job.id);
    log.info("processing", { id: job.id });
  },
});

// Scheduler: runs in deployed environments, not locally.
export const nightly = api({ expose: false }, async (): Promise<void> => {
  await jobs.publish({ id: `nightly-${new Date().toISOString().slice(0, 10)}` });
});

const _cron = new CronJob("nightly", {
  title: "Nightly job",
  schedule: "0 2 * * *",
  endpoint: nightly,
});

For a team leaving Heroku, the closest match is in what you no longer configure. You connect your AWS account, and Encore creates a VPC, a load balancer and Fargate or EKS as the AWS infrastructure guide describes. Pub/Sub maps to SNS and SQS, a database maps to RDS, and cron jobs run on schedule in deployed environments. Encore provisions an IAM role for the service, and with ECS on Fargate there is no Kubernetes cluster to keep up to date.

Locally, encore run starts the web endpoint, the worker and the queue, and you call nightly by hand to test the scheduled path. The same code deploys to GCP if you need it.

Key features

• Web, workers and cron from one codebase.
• ECS on Fargate or EKS.
• Separate infrastructure per environment.
• Postgres, Pub/Sub, cron and buckets in your own AWS or GCP account from the same code.

~/orders — claude

Claude Code v2.1.180Opus 5.5~/orders

Good to know

Encore deploys apps written with its TypeScript or Go SDK, so a Heroku app in Rails or Django is rewritten or kept elsewhere. Arbitrary Docker images are not its model.

Porter: a Heroku-style dashboard on EKS, and the cluster stays if you leave

Porter

Porter runs apps on an EKS cluster it creates in your account, with add-ons or RDS for data, and also supports GCP and Azure. Pricing is $6 per GB of RAM and $13 per vCPU a month, on top of what AWS bills.

The appeal for Heroku teams is the exit: Porter states that servers keep running and the cluster stays intact if you stop paying. What you take on is an EKS cluster in your account, with its control plane fee and the Kubernetes upgrades that come with it.

Northflank BYOC: many languages and clouds, billed by the managed vCPU

Northflank

Northflank BYOC deploys services and managed addons into an EKS cluster in your account, and also supports GCP, Azure and Oracle. It bills per managed node vCPU by the second, with no seat charges, and the free Sandbox includes one BYOC cluster up to 12 vCPU and 48 GB of memory. Any Docker image works, which suits teams with more than one language.

Qovery: a platform layer over EKS that agents can use

Qovery

Qovery manages EKS clusters in your account, as well as on GCP, Azure and Scaleway, and deploys apps and databases onto them. Plans are sized by clusters and users with a 14-day trial, and agents connecting through its MCP server do not count as users. It suits teams that want a platform over Kubernetes they may later take over themselves.

Ravion: AWS services through modules, without Kubernetes

Ravion deploys to ECS, Lambda and other AWS services from a ravion.yaml config, with RDS and ElastiCache as Terraform modules behind approval gates. It is free for one user with 50 modules and 2,000 pipeline minutes, then priced per module per environment, with no markup on AWS. It comes from the Flightcontrol team, offers no Flightcontrol migration, and Flightcontrol still works.

Coolify on EC2: self-hosted, with nothing between you and the server

Coolify is an Apache 2.0 self-hosted platform. On an EC2 instance with at least 2 cores, 2 GB of RAM and 10 GB of disk, curl -fsSL https://cdn.coollabs.io/coolify/install.sh | bash installs it, and the dashboard opens on port 8000, where the first account to register becomes the admin. Register straight away, and back up /data/coolify/source/.env. Databases run as containers you back up, and the instance is yours to patch.

What lands in your account

Every option here puts networking in your account, and most use a NAT gateway for private subnets, billed per hour and per GB. The Kubernetes-based platforms add an EKS control plane per cluster, and Kubernetes itself is a CNCF graduated project with a large ecosystem to draw on when you outgrow the platform.

Before you pick, list the processes your Heroku app runs today, with their add-ons and schedules, and check where each one would live on the new platform. The platform that maps that list with the fewest new pieces to operate is usually the right one.

How to choose

• Encore when you want web services, workers and cron jobs in TypeScript or Go deployed into your AWS account on git push, on ECS without a cluster to run.
• Porter for a Heroku-style dashboard on EKS, with the cluster staying yours.
• Northflank BYOC for many languages and clouds, billed by the vCPU.
• Qovery for a platform over EKS that agents can drive through MCP.
• Ravion for AWS services through reviewed Terraform modules, without Kubernetes.
• Coolify on EC2 for a self-hosted platform on a server you control.

Related guides

• Heroku alternatives in 2026
• Bring your own cloud
• Migrate from Heroku to AWS
• Deploy to AWS without Kubernetes