A Heroku Alternative for India: Move Your App, Step by Step

Many developers in India start on Heroku, and many look for a Heroku alternative once the app matters. The usual reasons are simple: the bill is in US dollars, and Heroku’s standard plans run in the US and Europe - its Mumbai region is only for the higher-priced Private Spaces, as its own regions page shows. This post covers what to check in an alternative and how the move works.

What to check in an alternative

The same workflow

Heroku’s best idea is push-to-deploy. Keep it. Your alternative should deploy from GitHub on every push, with rollbacks. Read how push-to-deploy works if you want the details.

Servers in India

If your users are in India, the server should be too, on every plan. On Voroa, services run in Mumbai, including the free size.

Billing that works for an Indian business

Rupee pricing, a GST invoice, and no foreign-currency charge on the card. Voroa bills in rupees with a GST invoice. What the same app costs on Heroku, worked through in rupees, is in our Heroku pricing guide.

The pieces you use

List what your Heroku app uses today: web dynos, worker dynos, scheduler jobs, Postgres, Redis. Each needs a home on the new platform.

How the move works

1. Connect the same repository

Your code does not change. Connect the GitHub repository to a new web service. The steps are in how to deploy from GitHub.

2. Copy your config vars

Heroku calls them config vars. Here they are environment variables. Copy each one across.

3. Check the start command

A Procfile line like web: node server.js becomes the service’s start command. A worker: line becomes a background worker, and Heroku Scheduler jobs become scheduled tasks.

The port

Heroku sets PORT, and so does Voroa. If your app already reads process.env.PORT, nothing changes.

4. Move the database

Create a managed PostgreSQL database and import your existing data. Then point DATABASE_URL at it.

5. Switch the domain

Add your domain to the new service, wait for HTTPS to be ready, then update DNS. Keep the old app running until traffic has moved.

Before you switch

Test the new service on its Voroa URL first. Run a few real flows - sign up, pay, upload - against the new database. Once it works there, the domain switch is the only step your users notice.

After the move

Watch the runtime logs for a day, compare error rates with the old app, and only then turn the Heroku app off.

Common migration problems

• An add-on has no direct match. Check each Heroku add-on and decide whether it moves to a managed service, to your own code, or to a third-party provider you call over the internet.
• Buildpack-specific settings. Settings that only a Heroku buildpack reads need an equivalent build or start command.
• Hard-coded Heroku URLs. Search the code for herokuapp.com before you switch the domain.
• Background jobs stop running. A worker dyno that was not recreated as a background worker means queued jobs silently pile up - check it on day one.

Move to Voroa

For sizes and prices, see web app hosting on Voroa.