Hosting for Startups: Pick What You Will Not Have to Leave

The right hosting for a startup is not the cheapest or the most scalable. It is the one you will not have to leave in eighteen months, because the migration is what costs you — not in hosting fees, but in a quarter of engineering time spent moving instead of building.

Advice on this topic reliably optimises for the wrong moment. It compares free tiers and first-year prices, which matter for about a month, and says nothing about the decision that costs real money: whether the architecture you start with survives the point at which the company is working. That is when moving is most expensive and least convenient.

The mistake in both directions
What actually changes between year one and year two
The questions to ask before choosing
What is genuinely worth having early
Free tiers and credits, honestly
What a sensible year-one setup looks like
How this fits the rest of the stack
FAQ

The mistake in both directions

There are two failure modes and they look like opposites.

Under-building. Everything on the cheapest possible arrangement — one shared box, a database on the same machine, deployment by copying files. It works for months. Then traffic arrives, or a second engineer joins, and there is no staging environment, no deploy history, no way to roll back, and no way to add a worker without an afternoon’s work. The team stops shipping and starts firefighting.

Over-building. Kubernetes, a service mesh, three environments, and infrastructure-as-code for a product with eleven users. Months of engineering spent on a platform for scale that has not arrived and may never, while a competitor with a boring monolith on a boring platform ships features.

Over-building is the more fashionable mistake and the more expensive one, because the cost is paid immediately and continuously rather than at a future point that may not come. Every additional piece of infrastructure is something to configure, monitor, upgrade, and debug, forever.

The correct position is neither: something simple that has an obvious next step. Not built for scale, but not built into a corner.

What actually changes between year one and year two

Predicting traffic is guesswork. Predicting the structural changes is not, because they are nearly universal.

A second engineer, then a third. Suddenly the deploy process needs to be something more than one person’s knowledge, and two people need to work without breaking each other’s environment.
A background worker. Emails, exports, imports, scheduled reports. Something that must not happen inside a request.
A staging environment, usually after an incident that a staging environment would have caught.
Database growth past the point where the original instance is comfortable, and a need for backups you can actually restore from.
A traffic spike — a launch, a press mention, a campaign — that is either the best day or the worst.
Compliance questions from the first customer who has a procurement process. Where is the data, who can access it, what is the backup policy.

Every one of those is foreseeable on day one. The useful exercise is not predicting your traffic curve; it is asking, for each item on that list, whether your current setup accommodates it with a configuration change or requires a migration.

If most of them require a migration, you have chosen hosting that expires.

The questions to ask before choosing

Five, in order of how much they cost to get wrong.

Can I add a background worker without changing platform? This is the most commonly needed and most commonly missing capability. A platform that runs only web processes forces you into awkward workarounds — cron endpoints hit by an external scheduler, work done inside requests that times out — long before you would otherwise move.

Does the database move with me? A managed Postgres or MySQL you can dump with standard tools is portable to anywhere. A proprietary datastore is not. This is the single strongest form of lock-in, because moving compute is a redeploy and moving data is a project with a downtime window.

What happens on the day traffic multiplies by ten? If the answer involves a migration, that is a plan to have an emergency during your best week. If it is a setting, or automatic within a ceiling you chose, it is fine.

Is the deploy process something a new engineer can use on their first day? If deployment requires knowledge that lives in one person’s head, that is a bus factor and a bottleneck. It should be push to a branch, and there should be a log showing what happened.

Can I roll back? Not in principle — in one action, in under a minute, at 11pm. This is the capability you need exactly when you are least able to improvise.

A platform that answers all five is worth more than one that is cheaper and answers two.

What is genuinely worth having early

A short list, because the point is not to build everything up front.

Deploy from a repository, with a build log. Not files copied by hand. This is the foundation everything else sits on.
A rollback target. The previous release still available, one action away.
A managed database with automatic backups. Running your own database on the application server is the most common early decision that becomes expensive.
Environment variables in the platform, not in the repository. Rotating a credential should be one change.
Logs you can read without SSH. Build logs and runtime logs, in the same place.
A staging environment, once there are two engineers. Before that it is optional; after that it is not.
Uptime monitoring. Something other than a customer should tell you the site is down.

That list is achievable in an afternoon on a decent platform and takes a week to assemble from parts. Notably absent: container orchestration, a service mesh, multi-region deployment, infrastructure-as-code, and a microservice architecture. Those solve problems you do not have, and each one has an ongoing cost in attention that a small team cannot spare.

The monolith is fine. It is more than fine — it is the correct architecture for a small team, because the coordination cost of services exceeds their benefit until you have enough people that coordination is already the problem.

Free tiers and credits, honestly

Startup programmes offering substantial cloud credits are common and worth taking, with two caveats that are worth stating before the money arrives.

First, credits expire. Building on an architecture that is affordable because of a credit means facing the real bill on a fixed date, and the real bill for a cloud architecture assembled without cost discipline is frequently a multiple of what the same workload costs elsewhere. Teams have been surprised by this at exactly the wrong moment in a funding cycle.

Second, credits encourage over-building. When compute is free, every managed service looks attractive, and you end up with eleven services wired together and no idea which ones you need. The complexity outlives the credit.

The disciplined approach is to build what you would build if you were paying, take the credits, and let them extend your runway rather than expand your architecture. Check the real cost of your setup at the start rather than the end.

Genuine free tiers are different from credits and worth knowing apart. A free tier that persists is a real thing to run a small service on. RunxBuild’s Free plan gives 0.1 vCPU and 512MB with 15 free days each month and $1.80 after — small, and honest about being small, which is more useful than a large credit with a cliff at the end.

What a sensible year-one setup looks like

Concretely, for most software startups, this is enough:

One web service running the application, deployed from the main branch, with build and runtime logs and rollback.
One managed database — Postgres or MySQL — with automatic backups, on a private network with the service.
One background worker for anything that should not run in a request, deployed the same way.
Object storage for user uploads, so they are not on the application’s disk.
A staging environment once there is a second engineer.
Environment variables in the platform, applied at deploy.
Uptime monitoring and error tracking.

That handles a substantial amount of traffic, is understandable by a new hire in a morning, and every piece of it grows by changing a plan rather than by changing architecture.

It also costs very little. On the RunxBuild ladder, a Basic service at $6 with a managed database beside it is the shape of a real year-one setup, with autoscaling between a floor and a ceiling plan so a launch is a configuration rather than an incident. The specific numbers matter less than the property: each piece is priced individually and each grows on its own.

When you outgrow it, you will outgrow one piece at a time — a larger database, a second worker, a service split out — rather than outgrowing the whole arrangement at once. That is the actual goal. Not a setup that scales forever, but one that never requires you to stop and move everything.

How this fits the rest of the stack

Choose hosting on what happens in year two: whether you can add a worker, whether the database is portable, whether a traffic spike is a setting, whether a new engineer can deploy on day one, and whether you can roll back at 11pm. Those five questions matter more than the first-year price, because the cost of getting them wrong is a quarter spent migrating instead of building. The RunxBuild hosting calculator prices the service, the worker, the database, and the storage separately, which is the right way to see whether a setup grows one piece at a time or all at once.

Useful related references:

FAQ

What hosting should a startup use?

Something with the smallest setup that has an obvious next step: deploy from a repository with logs and rollback, a managed database with backups, and the ability to add a background worker without changing platform. Avoid both extremes — copying files to one shared box, and Kubernetes for eleven users.

How much should a startup spend on hosting?

Very little in year one. A web service, a managed database, and a worker on a modest plan handles a great deal of traffic. If the bill is significant before the traffic is, the usual cause is over-building — an architecture assembled while credits were paying for it, whose complexity outlives the credit.

Are startup cloud credits worth taking?

Yes, with discipline. Build what you would build if you were paying, then let the credits extend your runway rather than expand your architecture. Credits expire on a fixed date, and an architecture that only made sense while compute was free produces a bill at a moment in the funding cycle when you least want one.

When should a startup move off shared hosting?

When any of these is true: you need a background worker and cannot have one, deployment is copying files by hand, there is no way to roll back, or the database lives on the same machine as the application. Those are structural limits rather than performance ones, and they bite before traffic does.

Should a startup use microservices?

Almost certainly not. The coordination cost of services exceeds their benefit until the team is large enough that coordination is already the problem. A monolith deployed from one repository, with a separate worker for background jobs, is the correct architecture for a small team and remains so for longer than most people expect.