Migrating from Heroku to AWS using Tapitalee

If you've landed here, there's a good chance you typed something like "move Heroku app to AWS" into a search box, skimmed a few results, and came away thinking it sounds like a lot: VPCs, IAM roles, load balancers, container orchestration, a dozen acronyms you'd have to learn before you could even deploy a hello-world. That reaction is reasonable. Raw AWS is a lot.

The good news is that you don't have to learn all of it. Tapitalee sits on top of AWS and gives you back the thing you liked about Heroku: an app, some processes, a handful of variables, a few add-ons, and one command to deploy. The difference is that everything ends up in your own AWS account, on your own AWS bill, and you can see it all in the AWS console if you ever want to.

We've written a number of posts and guides about different corners of this move. This post is the overview that ties them together: what actually changes, what stays the same, how long it takes, what it costs, how AI can take most of the tedium out of it, and where to go for the details.

The short version: your mental model still works

Tapitalee was designed by people who ran apps on Heroku for years, so the concepts line up almost one-to-one. A dyno is a container. A Procfile entry is a process. Config vars are variables (with an optional "secret" flag). Heroku Postgres is an RDS instance. git push heroku main is tapit image deploy. Release phase, one-off dynos and the Scheduler all become commands that you run before a deploy, on demand, or on a cron schedule.

Our Porting from Heroku post walks through each of these mappings one at a time, and the Porting from Heroku docs have a heroku-to-tapit command cheat sheet. If you know the left-hand column, you're most of the way to knowing the right-hand one.

How Tapitalee is different

• You bring the AWS account. Tapitalee is the control plane; the resources are yours. If you ever stopped using Tapitalee, your app would keep running. Nothing sensitive is stored on our servers.
• Your bill is the AWS bill. Tapitalee is a flat subscription with no markup. Compute is per-second, so a preview app that lives for a two-hour code review costs cents, and spot containers for workers cost about a third of on-demand.
• Add-ons are real AWS services. A Postgres add-on is an RDS instance you can see in your console, with the networking and IAM wired so only your app can reach it. Daily snapshots are on by default.
• Private by default. Only your web process faces the internet. Databases only accept connections from the app unless you say otherwise. Private Spaces-style isolation is the default, not a $1,000/month upsell.
• Any region, real cron, real disks. Not just US and EU. Scheduled commands take full cron expressions, and you can attach a persistent EFS volume if you need one.
• Nobody needs AWS credentials. Developers deploy, tail logs and open consoles through Tapitalee. Removing a team member revokes everything at once.

What it costs

The honest answer is "less, usually a lot less, plus a flat Tapitalee fee". In our Heroku vs AWS cost comparison we priced three typical workloads side by side.

Tapitalee also shows you the monthly AWS cost of a container or database in real time as you create or resize it, so there are no surprises when the first bill arrives.

How long does it take?

For a typical Rails, Django or Node app with a Postgres database and a worker, an afternoon. Most of that elapsed time is waiting for AWS to provision an RDS instance and copying data; the part where you actually type commands is short. The ordered checklist, with the heroku and tapit commands next to each other, is in Steps to porting an app. Boiled right down, it's:

Larger teams take longer, but that's mostly about process rather than technology. Our case study of moving a SaaS product from Heroku to AWS covers a $50-100M ARR Rails company that took about two months: staging first, then preview apps for every pull request, then a rehearsed production cutover in a three-hour maintenance window. They ended up with lower costs, a faster app, and a gated release workflow they didn't have before.

Let AI do the boring parts

This is where 2026 is different from the last time you looked at AWS. You almost certainly have a coding agent open right now, and the tapit CLI is a plain, predictable verb resource key=value tool that agents handle well. Tapitalee ships a Skill file that teaches Claude, Cursor and friends how to use it, and the porting docs above are written to be pasted into a prompt as much as read by a human.

In practice that means prompts like these just work:

• "Here's my Procfile and the output of heroku config and heroku addons. Following the Tapitalee porting steps, write the tapit commands to recreate this app, and tell me which config vars I should drop because an add-on will supply them."
• "Map my Heroku Postgres standard-2 and my Heroku Redis premium-0 to sensible RDS and ElastiCache sizes, and explain the monthly cost difference."
• "The first deploy failed its health check. Run tapit show events and tapit show logs and tell me what's wrong."
• "Convert these three Heroku Scheduler jobs into scheduled commands with cron expressions."

If you'd rather not set anything up locally, there's an in-browser chat bot in the Tapitalee dashboard with read-only access to your app. Ask it a question, and if it wants to change something it shows you the exact commands first and waits for your approval.

The reason this is safe rather than terrifying is that the agent is never holding your AWS keys. When you run tapit login you can restrict the session to read-only, and you can hand a long-running agent a scoped token that can see logs and metrics but not secrets. The boundaries are enforced by Tapitalee, not by a polite system prompt. You can even give an agent a read-only copy of production data and immutable backups can prevent anyone ever deleting them.

Keeping humans in the loop

This is the part that matters most, and it's why we'd steer you towards Tapitalee rather than having an agent generate a pile of Terraform. Getting onto AWS quickly is one thing; being able to understand and operate what you've built six months later is another. An AI can absolutely produce working CloudFormation for a VPC, an ALB, an ECS cluster, RDS and a CI pipeline, but this then falls on you and your team to maintain the lines of infrastructure code and the raw AWS console to navigate.

With Tapitalee the end state is the same shape as the thing you left: a dashboard and a CLI with apps, processes, variables and add-ons. Deploys are one command, roll back automatically if health checks fail, and can be rolled back manually by redeploying an earlier tag. Logs are tapit show logs -f. A console is tapit run 'rails console'. New team members are productive on day one because there's nothing difficult to learn, and the AWS resources underneath are standard, well-understood services rather than a custom stack.

And when you need more than Heroku offered, it's a configuration change rather than a rebuild. Our Dev Team Release Workflow post walks through four levels, from deploying off a laptop to CI deploys, preview apps for every pull request, and finally approval gates with a full audit trail ready for an enterprise security review. Most teams start at level one or two and turn the rest on as they grow.

Where to start

• Want the concepts first? Read Porting from Heroku.
• Want the numbers? Read the Heroku vs AWS cost comparison.
• Want to just do it? Follow Steps to porting an app, with your coding agent alongside.
• Want to see how a real team did it? Read the case study.
• Want a hand? Get in touch. We're knowledgable about migrations and are happy to talk through your add-on list and spot any blockers before you start.

Moving off Heroku doesn't have to mean becoming an AWS expert. It can mean keeping the workflow you already like, paying AWS prices for it, and having an AI assistant handle the fiddly bits along the way.