Heroku is enough
- One web app, a few add-ons, git push. You do not want to touch a server.
Heroku proved deployment does not have to be a ritual. The model behind it is rented runtime. When load, a native app or an EU server show up, that model gets expensive or the wrong shape.

Heroku taught a generation that deploy does not have to be a ritual. What remains is the model: you rent runtime, not a machine. Once load, compliance or a native app appear, that model gets expensive or the wrong shape.
A Heroku alternative does not need to be “the same, cheaper”. It needs to keep the push habit and put the bill on infrastructure you actually own.
This reflects the typical scope of both platforms. Details change over time, so check the current information from each provider when it matters.
| Criterion |
|
|
|---|---|---|
| Deploying a web application | Fully covered: A prepared GitLab CI pipeline per project | Fully covered: Very simple, a push triggers build and release |
| Language and framework coverage | Fully covered: Templates for Next.js, NestJS, Laravel, FastAPI, Astro and Hugo | Fully covered: Broad buildpack support across many languages |
| Marketplace for managed extras | Partly covered: No add-on marketplace, extra services run inside your own project | Fully covered: Large add-on marketplace for databases, queues and logging |
| Use your own servers | Fully covered: Your own server over SSH or a managed server from the platform | Not offered: Not supported, execution happens in dynos |
| Server baseline | Fully covered: Docker, databases, reverse proxy, SSL, firewall and backups are set up for you | Partly covered: Fully abstracted away, no access to the machine |
| How costs develop as you grow | Fully covered: Platform plus your own servers, which keeps the curve predictable | Partly covered: Priced per dyno and add-on, rising with instances and load |
| Free tier for trying things out | Fully covered: Register for free and create a first project | Not offered: No free tier available any more |
| Building mobile apps | Fully covered: Flutter, Expo and native iOS and Android projects including build environments | Not offered: Not part of the product |
| Publishing to App Store and Play Store | Fully covered: Metadata, screenshots and versions through Fastlane from inside the platform | Not offered: Not part of the product |
| Remote development environments | Fully covered: Ubuntu workspaces with VS Code, JetBrains, RDP and VNC. iOS builds on the pipeline’s macOS machines | Not offered: Not part of the product |
| Where processing happens | Fully covered: Operated in the EU with a data processing agreement, servers freely selectable | Partly covered: US provider owned by Salesforce, regions selectable |
Green means fully covered, amber partly, grey not offered. Heroku remains extremely comfortable for deployment – the difference lies in control, cost behaviour and reach beyond the web.
As of 9 September 2026. Based on the publicly documented feature scope of the providers named. Details can change; the provider’s current documentation takes precedence. Logos are trademarks of their owners and are used only to identify the product.
Heroku bills dynos and add-ons. We bill platform plus servers. Current Heroku plans are on the official pricing page.
Docker
Databases
Reverse proxy
SSL
Backups
Firewall
Kubernetes
Monitoring
The migration follows what you already have: a repository, an application and a database.
Attach your own server over SSH or book a managed one. Docker, databases, reverse proxy, SSL, firewall and backups get configured.
Set up your project in the wizard and pick the stack. The GitLab repository, project structure and CI/CD pipeline are created along with it.
What lives as config vars on Heroku goes into the project’s credential management and is handed to individual environments from there.
Load a dump into the prepared database, verify the application on a staging environment, then point the DNS record over.
Mostly cost and control: without a free tier, the bill grows with each dyno and add-on, and the machine itself stays out of reach. For teams in Europe, Heroku being a US provider inside Salesforce also matters.
In most cases yes, if it can run in a container. The platform deploys via Docker, so your code stays the same. What you replace is anything tied to Heroku: buildpacks become a Dockerfile, config vars become secrets, add-ons become your own services.
Server setup includes databases and their backups. The move is a dump and an import, ideally onto staging first. Since the database then lives on your own server, you decide size, version and maintenance windows yourself.
The workflow stays close: you push to your GitLab repository and the pipeline runs test, build and release. The difference is the steps live visibly in a file instead of a buildpack, so you can add your own steps too.
No. With a managed server the platform handles setup and maintenance. Connect your own server, and it configures Docker, reverse proxy, SSL, firewall and backups; daily operation stays with you. You can store cluster access; cluster deploy and full monitoring come next.
If dynos are no longer the right bill, you will see that faster in the wizard than in this table.