Overview
Migrating your application from Heroku to Aptible is a relatively straightforward process. Because Heroku is also a PaaS, there are many similarities in how applications are built and operated. However, there are a few key differences, primarily in how applications are packaged, deployed, and configured. This guide focuses on those deployment and configuration differences. It is also worth noting that Aptible differs from Heroku more broadly in its strong focus on security and compliance. Refer to the Security & Compliance docs for more information on those platform-level capabilities. This guide walks you through the general migration process for both your application and database, using a Node.js application with a PostgreSQL database as an example. If you are using a different framework, language, or database, most of the same steps will apply.FAQs for those migrating
Why migrate from Heroku to Aptible?
Why migrate from Heroku to Aptible?
Aptible is a security, compliance, and reliability-focused platform as a service (PaaS). Migrating to Aptible enables you to instantly adopt a stronger security and compliance posture, with built-in support for frameworks such as HIPAA, HITRUST, and SOC 2, while maintaining the ease of use and developer experience you may already be familiar with from Heroku.Teams typically migrate to Aptible when they need more robust security controls, stronger compliance guarantees, or higher reliability, without taking on the operational burden of managing their own infrastructure.
How does Aptible pricing compare to Heroku (including Heroku Shield)?
How does Aptible pricing compare to Heroku (including Heroku Shield)?
If you’re coming from Heroku’s standard platform, Aptible’s pricing model will feel familiar: usage-based billing, simple line items, and no long-term lock-ins or steep minimums.If you’re migrating from Heroku Shield specifically, Aptible differs in two important ways: Aptible does not require a 12-month contract, and Aptible does not enforce high minimum spend thresholds. This makes it easier to adopt without long-term financial commitments.
Before you begin
Before starting, you should:-
Create an Aptible account and select your plan
Sign up for Aptible here - by default, you should receive a 30-day free trial.
To begin your migration, you will need to select a plan:
- Development is intended for early-stage development and testing, when you do not yet have production security or compliance requirements.
- Production is designed for production workloads and provides access to highly secure and compliant resources, including support for frameworks such as HIPAA.
-
Install the Aptible CLI
Install the Aptible CLI on your local machine. The CLI is used to authenticate, manage environments and apps, and deploy your code.
Install the CLI here. -
Review your existing Heroku setup
Before migrating, make note of the following details from your existing Heroku setup, as you will apply them throughout this guide:
- Application process types (web, worker, background jobs)
- Environment variables and secrets
- Add-ons such as databases, caches, or third-party services
- Any custom build or runtime configuration
- Networking or domain configuration
Key considerations
While Aptible and Heroku are similar in many ways, there are a few important differences in how applications are built, deployed, and run. This section highlights those differences before moving on to the step-by-step migration guide.Platform Constraints
Aptible and Heroku share several operational constraints:- Applications run on Linux inside containers.
- Incoming application traffic is supported over ports 80 (HTTP) and 443 (HTTPS).
- Applications are expected to be stateless and ephemeral.
Aptible requires Docker
Aptible requires applications to be built and run as containers, which means every application must include a Dockerfile. If your application is not already containerized, not to worry. Adding a Dockerfile is usually straightforward, and Aptible provides guidance and examples to help you get started. Aptible supports two deployment workflows:- Deploy from Git, where you push your code to Aptible and Aptible builds the Docker image for you using your Dockerfile.
- Deploy from a Docker image, where you build the image yourself and have Aptible pull and run it from a registry.
Procfiles are optional
Heroku requires a Procfile to define application processes. Aptible does not. If no Procfile is present, Aptible will infer the service command from the Dockerfile CMD instruction. This is referred to as an Implicit Service. You can continue using a Procfile if your application has multiple services or process types. Procfile syntax is standardized and compatible between Heroku and Aptible. Depending on your deployment method, the Procfile location differs:- Dockerfile Deploy: keep the Procfile in the repository root.
- Direct Docker Image Deploy: move the Procfile to
.aptible/Procfile.
.aptible.yml configuration file. Its placement follows the same rules:
- Root directory for Dockerfile Deploy
.aptible/.aptible.ymlfor Direct Docker Image Deploy
Private Registry Authentication
If you deploy images from a private Docker registry, you must configure Aptible with credentials that allow it to pull your images. This is done using environment variables or the Aptible CLI before deploying.Step-by-step guide
This section walks through a typical Heroku to Aptible migration. We’ll use a Node.js app with PostgreSQL as an example, but the same workflow applies to most applications.1. Add a Dockerfile (if you don’t have one already)
Aptible requires a Dockerfile. If your Heroku app used buildpacks and did not include one, you’ll need to add it before deploying. Node.js example Dockerfile Create a Dockerfile:CMD utility to accomplish this. CMD accepts an array of individual words. For instance, for npm start, we could do:
2. Migrate over Procfiles (if applicable)
Heroku typically uses a Procfile to define process types (e.g.,web, worker). Aptible supports Procfiles, but they are optional.
- If you do not use a Procfile, Aptible will infer the command from your Dockerfile
CMD. - If you do use a Procfile, you can keep using it.
.aptible/Procfile:
3. Set up Aptible’s remote
If you haven’t already, provision an environment and app in the Aptible UI. Then add the Aptible Git remote.4. Migrate your databases
If your Heroku app uses a database (such as Heroku Postgres), you’ll migrate that data into a new Aptible-managed database. Similar to Heroku, Aptible supports automated backups, replicas, failover logic, encryption, network isolation, and automated scaling. Beyond provisioning a new database, you will need to migrate your data from Heroku to Aptible. You may also want to put your database in maintenance mode when doing this to avoid additional data from being written to it during the process. You can accomplish that by running:latest.dump, which needs to be converted into a SQL file to be imported into Postgres. We can do this by using the pg_restore utility. If you do not have the pg_restore utility, you can install it on Mac using Homebrew or Postgres.app, and one of the many Postgres clients on Linux.
data.sql) into the database.
aptible, postgres, and the database db already exists. These are okay. You can learn more about potential errors by reading our database import guide here.
5. [Deploy using Git] Push your code to Aptible
If we aren’t going to use the Docker registry, we can instead directly push to Aptible, which will build an image and deploy it. To do this, first commit our changes and push our code to Aptible.6. [Deploying with Docker] Private Registry registration
If you used Docker’s registry for your Heroku deployments, and you were using a private registry, you’ll need to register your credentials with Aptible’sconfig utility.
7. [Deploying with Docker] Deploy with Docker
While you can get a detailed overview of how to deploy with Docker from our dedicated guide, we will summarize the core steps. Most Docker registries supply long-term credentials, which you only need to provide to Aptible once. We can do that using the following command:--docker-image tag on subsequent deploys.

