Where to Host a Small Integration Backend: Heroku and Its Alternatives
Not every backend is a big application. Some of the most valuable software I have built is small. It receives webhooks from Shopify, talks to a shipping system, keeps a little data in a database, and runs a few scheduled jobs. In one project that was a lightweight Heroku app sitting between a store and its fulfillment tools, which I describe in Bridging Shopify and ShipStation on Heroku.
A system like that has a particular profile. Traffic is low, but the cost of it being down is high, because a stopped integration means orders that quietly stop moving. So the question of where to host it is not mostly about price. It is about reliability, simplicity, and who gets woken up.
What a small integration backend needs
Before comparing platforms, write down what yours actually requires. Mine usually looks like this:
- A web process that can receive webhooks at a stable address, with a valid certificate, and answer within a few seconds.
- One or more worker processes for background jobs.
- A Postgres database with automatic backups.
- A Redis instance if you use Sidekiq or another queue.
- A scheduler for recurring jobs, such as a reconcile task.
- Logs you can search, and an easy way to see errors.
- Deploys that are boring: push code, wait, done, and a quick way to roll back.
- Secrets stored safely outside the code.
If a platform covers those with little effort, it will serve you well. Anything beyond that is a bonus you may never use.
The one trap: sleeping and cold starts
The failure I see most on small apps is a web process that goes to sleep. Some plans on some platforms stop idle processes after a period of no traffic and wake them when a request arrives. For a website that is a minor annoyance. For a webhook receiver it is a problem, because the sender is waiting, and the wake up delay can exceed the time it will tolerate. The sender then counts the delivery as failed.
Whatever you choose, confirm that your web process stays awake at all hours and that your workers run continuously. Read the plan details carefully, since this is the cheapest tier to get wrong.
Staying on Heroku
Heroku is still a perfectly reasonable answer. Its strengths are the same as when it became popular: deploying from git is simple, add ons for Postgres and Redis are a click away, and there is very little to maintain. For a small team without a dedicated operations person, that simplicity has real value.
The downsides are cost and the fact that you pay for each piece separately. A web process, a worker, a database and a Redis instance each have their own price. The free tier that many hobby projects relied on ended a few years ago, so tiny projects now carry a monthly bill. Compare the current prices honestly with what you actually use.
If your integration works, makes money for your business, and costs a modest amount, the best move might be to leave it alone. Migrating a working system has its own cost and risk.
Other managed platforms
Several newer platforms offer a similar experience, where you connect a repository and the service builds and runs it. Render, Fly.io, Railway and DigitalOcean’s app platform are the ones I am asked about most. They differ in pricing models, regions, how they handle databases and how mature their tools are. I will not quote prices here because they change often, so look at each one’s current page.
What I would evaluate on each:
- Does the cheapest plan that fits keep processes awake?
- Are database backups automatic, and can I restore one easily?
- How are workers and scheduled jobs handled?
- What do deploys and rollbacks feel like?
- What is the support story when something breaks at an awkward hour?
- How hard is it to leave later? Check that nothing locks your data in.
Run a small trial with a realistic workload before moving anything important.
A virtual server you manage yourself
A plain virtual server from a hosting company can be far cheaper for the same capacity, and it gives you complete control. Many Rails developers now deploy to a server with containers, using tools designed for exactly that. You pay with your own time: you handle operating system updates, firewall rules, backups, monitoring and restarts.
That trade can be excellent if you have the skills or someone to rely on. It is a poor trade if nobody will notice when the disk fills up. I did exactly this kind of work in Cutting AWS Costs by Over 50%, where the savings were real but depended on planned maintenance. Cheaper hosting is only cheaper if someone owns the upkeep.
The database deserves the most attention
Moving a web process is easy. Moving a database is the part that can hurt. Whatever you choose, ask:
- Where are backups stored, and how often do they run?
- Have I ever restored one into a clean database to prove it works?
- How long would recovery take if the database were lost?
- Is the data in a region and under rules that fit my business?
If your integration stores anything you cannot recreate from Shopify or another source, treat backups as a feature you test, not a box you tick.
Monitoring matters more than the platform
A small backend on any platform is only as dependable as your awareness of it. At minimum I add:
- An uptime check that calls a simple health address every minute and alerts someone if it fails.
- An error tracker, so exceptions in workers do not disappear into logs.
- An alert on queue depth, so a stuck worker is noticed within minutes.
- A daily report of orders that did not complete.
These cost little and prevent the most expensive kind of outage, which is the one nobody noticed.
How I would decide
Here is the simple version:
- If it works today and the bill is reasonable, stay put.
- If cost is the problem, look at one of the newer managed platforms first, because the effort is small.
- If you have a very steady workload and technical help available, a managed virtual server can save the most money.
- If you are starting fresh, pick the platform your team can operate comfortably at 2 AM, then add monitoring on day one.
The best hosting is the one you stop thinking about. If you are weighing a move, or you inherited a small app and are not sure it is safe where it lives, email kevin@kevinhq.com with a list of the services it uses. I can tell you what I would keep, what I would change, and what is not worth the effort.