“Cloud-first” is such settled advice that almost nobody examines it any more. Which is odd, because the people who coined the phrase stopped using it in 2018.<\/p>\n\n\n\n
Cloud First was a US federal policy, introduced in 2010 under then-CIO Vivek Kundra, telling agencies to prioritise cloud services. Eight years later the Office of Management and Budget replaced it with Cloud Smart<\/a>, and the stated reason was blunt: Cloud First had told agencies to move to the cloud without telling them how, and adoption had stalled because of it. The instruction was right. The absence of a decision framework behind it was the problem.<\/p>\n\n\n\n That is roughly where startup infrastructure advice still sits. Prioritise cloud. Use managed services. Adopt microservices when ready. All defensible, all missing the part where somebody tells you what it costs and in what order to do it.<\/p>\n\n\n\n So here is a different version. We build infrastructure for clients and we run our own products, and one of those products \u2014 a multi-tenant SaaS platform in production \u2014 runs on a nine-dollar-a-month server. Not as an experiment. Because when we did the arithmetic, that was the right answer. This article is the arithmetic.<\/p>\n\n\n\n These get used interchangeably and they are not the same thing.<\/p>\n\n\n\n Cloud First<\/strong> means defaulting to cloud services for new workloads rather than buying hardware. As a 2010 policy correcting for organisations that reflexively bought servers, it was sensible. As a decision rule for a startup in 2026, it is close to meaningless \u2014 you were never going to buy a rack anyway.<\/p>\n\n\n\n Cloud Smart<\/strong> is the correction: use cloud where it fits the workload, and be deliberate about where it does not. OMB built the update around security, procurement, and workforce skills, because those were the three places agencies actually got stuck. The underlying idea travels well to startups. The question is not whether to use the cloud. It is which parts, at what price, and what you are giving up.<\/p>\n\n\n\n Cloud Native<\/strong> describes how an application is built, not where it runs. Containers, orchestration, declarative infrastructure, services that scale independently. You can be cloud native on your own hardware, and you can run a thoroughly traditional monolith on AWS. Conflating the two produces a specific and expensive mistake: teams adopt Kubernetes because they are “on the cloud,” and inherit an operational burden their product did not require.<\/p>\n\n\n\n Cloud based<\/strong> just means it runs on someone else’s computer. It carries no architectural claim at all.<\/p>\n\n\n\n The distinction that matters for a startup: cloud native is an architecture decision with real ongoing cost, and it is separate from where you host. Treat them separately.<\/p>\n\n\n\n Scalable does not mean distributed. It does not mean microservices, Kubernetes, multi-region, or event-driven. Those are techniques for achieving scale under particular conditions, and every one of them adds operational cost you pay from the day you adopt it.<\/p>\n\n\n\n Scalable means: when load increases, you have a known next move that does not require rewriting the application.<\/strong><\/p>\n\n\n\n That is it. A single server running a well-structured monolith with the database on the same box is scalable if you know that the next step is moving the database to its own instance, and the step after that is adding a read replica, and the one after that is a second application server behind a load balancer. Each of those is a config change and a deploy, not a rewrite.<\/p>\n\n\n\n Conversely, a Kubernetes cluster running twelve microservices is not scalable if nobody on the team can debug a failing pod at 2am.<\/p>\n\n\n\n The failure mode we see most often in early-stage products<\/a> is not under-building. It is building the year-three architecture in month one, then moving slowly forever because every feature now touches four services and a message queue.<\/p>\n\n\n\n Concrete examples, since the abstract version is what every other article gives you.<\/p>\n\n\n\n LiftUp<\/a><\/strong>, our multi-tenant operations platform, runs on a single Hetzner<\/a> VPS at nine dollars a month. Application, database, and background workers on one box. Laravel, server-rendered views, nginx terminating TLS. It serves tenants in production.<\/p>\n\n\n\n qalbit.com<\/strong>, this site, runs on a separate VPS \u2014 a Next.js front end with headless WordPress behind it, PM2 keeping the Node processes alive, nginx in front.<\/p>\n\n\n\n Neither is on AWS. Neither uses Kubernetes. Neither has an auto-scaling group.<\/p>\n\n\n\n Before that reads as ideology: we build on AWS<\/a> regularly for clients, and for a good number of them it is the right call. Compliance requirements, existing organisational commitments, genuinely spiky traffic, or a team that already knows it \u2014 any of those tips the decision. What we object to is the default. The reasoning below is why the default did not survive contact with our own budget.<\/p>\n\n\n\n A small production web application needs, at minimum: compute, a database, a way to run background jobs, TLS, and somewhere to put files.<\/p>\n\n\n\n Assembled from managed services on a major cloud, each of those is a separate line item, and the ones that hurt are rarely the ones people budget for. A managed database with automated backups is typically the largest. Load balancers bill hourly whether or not traffic arrives. Data egress is metered, and it is the charge that scales with your product’s success rather than its size.<\/p>\n\n\n\n On a single VPS, most of those collapse into the instance price. The database runs alongside the application. Background workers are processes on the same machine. TLS is a certificate. Egress is included up to a generous cap.<\/p>\n\n\n\n The tradeoff is real and worth naming: you now own patching, backups, monitoring, and recovery. That is not free. It is a few hours a month when things are calm and a bad evening when they are not.<\/p>\n\n\n\n If you are one founder shipping one product and your own time is the binding constraint, pay for the managed platform. Render, Railway, Fly.io, or a PaaS on one of the big clouds will cost more per month and give you back the evenings you would have spent on server administration. That is a good trade, and it is what we recommend to most solo founders in our cloud work<\/a>.<\/p>\n\n\n\n We run our own because we operate several products and have people who are comfortable doing it, so the fixed cost of that knowledge spreads across everything. One product does not amortise it.<\/p>\n\n\n\n Two things belong in this section that most startup infrastructure advice leaves out.<\/p>\n\n\n\n AWS Activate<\/a>, Google Cloud for Startups<\/a>, and their equivalents hand out substantial credits. Every article about startup infrastructure lists this as a tip. Almost none of them mention the mechanism.<\/p>\n\n\n\n The credits work because architecture is sticky. You build against a provider’s managed services during the credit period, and by the time it ends your application depends on their queue, their managed database, their auth service, and their object storage semantics. The bill arrives at exactly the point you have the least capacity to do anything about it \u2014 usually just after the credits expire and just before you close a round.<\/p>\n\n\n\n That is not a reason to refuse the credits. It is a reason to spend them on things you can leave: compute, storage, and managed versions of things with portable equivalents. Every proprietary service you build against is a switching cost you are agreeing to.<\/p>\n\n\n\n Hetzner has been the price\/performance answer in European hosting for years. Then it raised prices twice in 2026 \u2014 on 1 April across the lineup by up to 37%, applied to existing customers, and again on 15 June where the dedicated and AMD shared vCPU families went up 113\u2013176%. A CCX13 went from \u20ac15.99 to \u20ac42.99 a month, which puts it at parity with an equivalent DigitalOcean droplet and removes most of the reason you would have chosen it on price.<\/p>\n\n\n\n There is an operational detail worth knowing if you run there: existing servers keep their old pricing until you rescale, at which point you reprice at current rates. The instinctive response to growing load is to bump the instance size, and doing that can multiply your bill by more than the resources you gain. Price the new tier before you click.<\/p>\n\n\n\n The lesson is not about Hetzner. It is that any cost advantage based on a provider’s pricing is rented, and the rent can change. Keep your deployment boring enough to move: a process manager, a reverse proxy, a database, and a deploy script. Ours would take a day to relocate. That portability is worth more than the monthly saving.<\/p>\n\n\n\n Running your own servers is not an argument for building everything yourself. The line we draw is roughly this: manage your own infrastructure, buy your own undifferentiated complexity.<\/strong><\/p>\n\n\n\n Four things we would almost never build:<\/p>\n\n\n\n Payments and billing.<\/strong> Subscription state, proration, failed payment retries, tax, and regional mandate rules are a product in themselves. Stripe, Razorpay, or a billing layer on top of them will always be cheaper than your version. This is the clearest buy decision on the list.<\/p>\n\n\n\n Authentication, past a point.<\/strong> Email and password with sessions is a solved problem in every mature framework and you should just use it. SSO, SCIM provisioning, and enterprise identity are not, and the moment a buyer asks for them, a managed provider costs less than the six weeks.<\/p>\n\n\n\n Transactional email.<\/strong> Deliverability is a specialism involving reputation, authentication records, and bounce handling. Nobody should be running their own mail server for product email in 2026.<\/p>\n\n\n\n Object storage.<\/strong> S3-compatible storage is cheap, durable, and boring. Storing user uploads on your application server means they vanish on redeploy and stop being visible the moment you run two instances.<\/p>\n\n\n\n What we would keep in-house: the application, the database, and the queue. Those are where your product’s behaviour lives, and the managed versions mostly save you operational work rather than development work.<\/p>\n\n\n\n Provider comparisons usually turn into feature matrices. Four things predict how you will feel in a year.<\/p>\n\n\n\n Pricing that survives your growth.<\/strong> Not the headline instance price \u2014 what happens at ten times the traffic. Metered egress and per-hour managed services scale differently from a flat instance fee, and the difference compounds.<\/p>\n\n\n\n Exit cost.<\/strong> How much of your architecture assumes this provider? Compute and storage are portable. Proprietary queues, function runtimes, and managed auth are not. You are choosing a switching cost, so choose it consciously.<\/p>\n\n\n\n Support you can actually reach.<\/strong> Budget providers often have community forums and a ticket queue. The big clouds sell support as a percentage of spend. Both are fine; the failure is discovering which you have during an outage.<\/p>\n\n\n\n Regional presence and data residency.<\/strong> If you sell into the EU, where the data sits is a contractual question, not a latency question. This decides the provider for a lot of B2B products before anything else does.<\/p>\n\n\n\n For a startup MVP without specific compliance requirements, our honest ranking is: a managed platform if time is scarce, a plain VPS if money is scarce and someone can run it, and a major cloud when a customer, a regulator, or genuinely unpredictable load requires it. That third case is less common than the marketing suggests.<\/p>\n\n\n\n Resilience is where startup infrastructure advice gets least useful, because it is usually written from the perspective of companies with a hundred engineers.<\/p>\n\n\n\n The honest version for a small team, in the order the work is actually worth doing:<\/p>\n\n\n\n 1. Backups you have restored.<\/strong> An untested backup is a belief, not a backup. Restore one into a scratch environment and time it. Most teams discover their recovery time is hours longer than they assumed, and they discover it during an incident.<\/p>\n\n\n\n 2. Monitoring that wakes someone.<\/strong> An uptime check and error tracking. If a failure has to be noticed by a customer emailing you, nothing further down this list matters.<\/p>\n\n\n\n 3. Graceful degradation.<\/strong> When a third-party API is down, the page should render without that section rather than returning a 500. This is a code decision, costs almost nothing, and prevents most of the outages users actually notice.<\/p>\n\n\n\n 4. A documented recovery path.<\/strong> Not automated failover \u2014 written instructions for rebuilding from backup. One page. The value is that it forces you to discover what is missing.<\/p>\n\n\n\n 5. Redundancy.<\/strong> A second application instance behind a load balancer, a database replica. Real cost, real benefit, and correctly placed fifth.<\/p>\n\n\n\n Chaos engineering \u2014 the discipline Netflix popularised with Chaos Monkey<\/a> \u2014 is genuinely valuable and genuinely not your problem yet. It tests resilience you have already built. If steps one through five are incomplete, it will only tell you things you already know.<\/p>\n\n\n\n Most infrastructure advice is a list of things to have. This is a sequence, and the sequence is the useful part.<\/p>\n\n\n\nCloud First, Cloud Smart, Cloud Native: What the Terms Mean<\/h2>\n\n\n\n
What “Scalable Infrastructure” Actually Means<\/h2>\n\n\n\n
What We Actually Run<\/h2>\n\n\n\n
The arithmetic<\/h3>\n\n\n\n
When we would tell you to do the opposite<\/h3>\n\n\n\n
What Cheap Infrastructure Actually Costs<\/h2>\n\n\n\n
Cloud credits are a customer acquisition cost, not a discount<\/h3>\n\n\n\n
Cheap hosting is a rented advantage<\/h3>\n\n\n\n
When Managed Services Are Genuinely Worth It<\/h2>\n\n\n\n
Choosing a Provider: What Actually Matters<\/h2>\n\n\n\n
Designing for Failure Without Overbuilding<\/h2>\n\n\n\n
The Order to Add Complexity<\/h2>\n\n\n\n