Heroku has sadly been on a decline the past couple years. It's had numerous security and performance incidents. And it's also not being updated to support modern technology like HTTP2 for example. This is causing many Heroku users to explore other platforms.
Amazon Web Serivces (AWS) is one of the best alternatives and has the largest market share. Compared to Heroku, AWS is more performant, more secure, and provides more control and customization. And Heroku users will save up to 80% on infrastructure cost by migrating to AWS. But the downside of AWS is the complexity of setup and maintenance. That's where Flightcontrol comes into play.
Flightcontrol (opens in a new tab) drastically simplifies AWS by providing a Heroku-like deploy experience on your own AWS account. It can save weeks of frustration and setup, and provides a great on-going developer experience, unlike the native AWS console. But the unique thing about Flightcontrol is that, unlike Heroku, you retain full control and ownership of your infrastructure. This enables you to customize and tweak anything as you grow.
In short, a migration from Heroku to AWS will look like this:
- Deploy a test version of your application that's connected to your Heroku database
- Once everything is working, switch production traffic to AWS by updating your DNS records
- If everything is working, migrate the Heroku database to AWS
- Delete everything from Heroku
|Pipeline||Project||Top-level grouping for environments and services|
|Pipeline Stage||Environment||Dedicated environment like Production or Staging|
|Review Apps||Preview Environments||Temporary environments for each pull request|
|Dyno||Service||Typically an application such as a Ruby on Rails app|
|Add-ons (DB, Redis)||Services||In Flightcontrol, databases and Redis are first-class service types|
|Config Vars||Environment Variables||Injected runtime values that can be different for each environment|
|Buildpacks||Nixpacks||Unlike Heroku, you do not have to explicitly add multiple buildpacks. Nixpacks will automatically detect the correct configuration in most cases|
- Connect your GitHub account to Flightcontrol
- Create a new Flightcontrol project
- Copy any needed configuration like build and start commands
- We recommend selecting the
us-east-1AWS region since your Heroku app is already there
- Copy all the Config Vars from your production Heroku and add them as Flightcontrol Environment Variables
- This will enable the app running on Flightcontrol to read from your production database on heroku. Your app will be connected to production, but not yet serving production traffic
- Configure your Custom Domains in Flightcontrol. Adding your domain to Flightcontrol will not migrate traffic. It will display the DNS values you must change to migrate traffic.
- When ready to switch traffic, update your DNS records to the ones provided by Flightcontrol.
- Tip: save the previous DNS records so you can easily revert
- Ensure everything is working
If you need to revert and move traffic back to Heroku, change the DNS records to point back to Heroku
At this point, production traffic is being served by your new servers on AWS but using the old Heroku Database. To complete the migration, you'll need to create a new database in AWS via Flightcontrol. Then migrate the data from the Heroku to AWS database.
For details, see our guide on migrating Heroku Postgres to RDS
- Environment variables you may be using in your code that need to be updated include:
- AWS does not have the memory swap, so you can’t use memory above what’s available. If memory reaches 100% for a short time, the server may be restarted.
For users on our Team plan, we offer complimentary white glove migration support to help you at every step of the way and ensure that migration is a success for you and your users.