Self hosting vs cloud: which is cheaper?

It depends on how your load behaves, not on which is cheaper in general. For steady work that runs all day every day, self hosting is usually far cheaper over a few years, the cloud charges rent around the clock for a machine you could buy once. For spiky or occasional work that sits idle most of the time, the cloud wins easily, because you only pay while it runs. The mistake is paying cloud rental prices for a steady, always-on workload: that's renting a flat you never leave. Map your load first, then pick the model that fits it.

When should a small business self host instead of using the cloud?

Self host the steady core, file storage, internal tools, an always-on database, archival backup. Those run constantly and their cost is predictable, so a box you own beats a meter that never stops. Stay in the cloud for the spiky and the critical-uptime jobs: bursty compute, a website that must never go down, anything where someone else's redundancy genuinely beats yours. Most small businesses are best on a hybrid: own what's steady, rent what's spiky, and never let one provider's price rise or outage hold the whole business hostage.

What are cloud egress fees and why do they matter?

Egress fees are what a provider charges to move your own data out of their platform. Storing is cheap and getting data in is free, but pulling large amounts back out costs real money, and that's deliberate. The more you keep there, the more expensive it gets to leave, which is how a convenient service turns into a dependence you can't easily walk away from. Before you commit serious data anywhere, check the cost of a full export. If leaving is expensive, you don't own your data, you're renting access to it.

Is self hosting practical on the NBN in Australia?

For internal use, absolutely. For anything the public must reach, design around the NBN's asymmetry: most connections give plenty of download but single-digit-megabit upload, and a service you host serves outward, so it's capped by that weak upload. Inside your own network it's a non-issue. For a public-facing service, use a business plan with real upload, a small cloud front end that talks back to your box, or just keep the public part in the cloud and self host the rest. Don't push a busy public site out through a residential upload pipe.

What does "don't rent your dependence" mean?

It means don't let any single provider become something your business can't function or escape from. Renting compute is fine; renting your ability to operate is not. The test: if your main provider tripled its price, went down for a day, or shut your account, would you survive it? If the honest answer is no, you don't have a vendor, you have a dependence you're paying rent on forever. Own the parts you can't afford to lose control of, keep your data portable, and make sure you could move if you had to. You probably won't. Being able to is what keeps it honest.

What is a hybrid cloud setup?

A hybrid setup runs some workloads on infrastructure you own and some in the cloud, on purpose, split by what each does best. The steady, predictable, cost-sensitive work, storage, internal tools, always-on services, lives on hardware you control, already paid for. The spiky, bursty or uptime-critical work, public websites, occasional heavy compute, anything that benefits from someone else's redundancy, stays in the cloud, billed only while it runs. It's not a compromise. It's the answer most setups should land on: own the base load, rent the peaks, and keep one foot on ground you control.

// Notes from someone who builds the thing

Self hosting vs cloud: the cloud isn't always the answer

Here's my honest answer to self hosting vs cloud, from someone who runs both every day: it's not either-or, and "just put it in the cloud" is lazy advice that quietly costs people a fortune. The cloud is a rental. It's brilliant for work that's spiky, occasional or has to never go down, and a slow bleed for the steady, predictable stuff you could own outright. I run my own data centre and I still pay for cloud where it earns its keep. The trick isn't picking a side. It's knowing which workload belongs where, and never renting your dependence on someone else. Here's how I'd actually decide.

The cloud is a rental, and rentals have a sweet spot

Strip away the marketing and a cloud server is a flat you rent by the hour. That's not an insult, renting is exactly right for some things. If you need a beefy machine for two days a month, or your traffic triples every Black Friday and dies back down, renting is the only sane choice. You'd never buy a truck to move house once. You hire one.

But nobody rents a flat they live in full-time for twenty years and calls it the smart money move. And that's precisely what "put everything in the cloud" tells small businesses to do: pay a rental rate, around the clock, for a machine that does the same steady job every single day. The meter never stops. It runs while you sleep, while you're closed, over the Christmas break, for a workload whose size you could have predicted to the gigabyte. That's the case the cloud is quietly bad at, and it's the most common case there is.

The maths nobody runs before they sign up

Take a steady always-on workload, a database, a file store, an internal app that just has to be up. A capable server is a few thousand dollars once. The equivalent cloud instance, left running every hour of every month, rents for a meaningful chunk of that every year, and you never stop paying, and at the end you own nothing. Self host the same thing and after the first year or two the hardware is paid off and you're just covering power and your time. For a workload that genuinely runs all day every day, owning it is usually far cheaper over any sensible horizon. The cloud's pricing is honest about this if you read it: it's optimised for elastic, bursty load. Point it at a flat, steady line and you're paying peak rental for base-load work.

Two costs get left off the back of the napkin, and they're the ones that bite. Power isn't the scary number people think. A small always-on server in Sydney sips a few hundred kilowatt-hours a year, real money, but a rounding error next to twelve months of cloud rental for the same box. And the one that catches everyone: egress fees. Cloud providers make it cheap to store your data and free to put it in, then charge you to pull it back out. That's not an accident. The more you keep there, the more it costs to leave, which is how a handy service turns into a dependence you can't walk away from. Always check what a full export of your own data would cost before you trust a platform with it. If leaving is expensive, you don't own your data. You're renting access to it.

Where the cloud genuinely wins, and I use it

I'm not anti-cloud. I'd be a hypocrite; I pay for it where it's the right tool. Be honest about where that is:

Spiky and occasional work. Bursty compute, a once-a-month heavy job, a load that's idle most of the time. Pay only while it runs. This is the cloud at its best, and self hosting it would mean buying a big machine to sit idle.
Anything that must never, ever go down. A public service where minutes of downtime cost real money. A good provider's redundancy across multiple sites genuinely beats what most small operators can build alone, and that's worth paying for.
Global reach and getting started fast. Serving users on the other side of the world, or spinning something up tonight to test an idea before you've committed a cent to hardware. Renting first and buying once it's proven is just good sense.

Notice the pattern: the cloud earns its rent when the work is spiky, critical, or unproven. The moment a workload becomes steady, predictable and long-lived, the rental logic flips and ownership starts winning. That's the whole decision in one line.

The Australian catch: design around the upload

One hard local truth before anyone self-hosts a public-facing service: the NBN is lopsided. Most connections hand you generous download and a thin single-digit-megabit upload, and a service you host is serving outward, so it's gated by that weak upload, not your fast download. Inside your own four walls this is a non-issue; an internal file server or app screams along on the LAN. Push a busy public website out through a residential upload pipe, though, and it'll crawl. The fix isn't to abandon self hosting, it's to put the right layer in the right place: keep the public-facing front in the cloud, self host the steady internal core behind it, and let a small relay tie them together. Which is exactly the hybrid I'm about to argue for.

Own what's steady, rent what's spiky

So the real answer to self hosting vs cloud isn't a side. It's a split, and most setups should land on a hybrid. Here's the rule I actually apply:

Map the load before you map the bill. For each workload ask one thing: is it steady or spiky? A flat, always-on line is a buy. A jagged, occasional spike is a rent. Get that read right and the rest follows; get it wrong and you'll overpay whichever way you go.
Own the steady core. Storage, internal tools, the always-on database, archival backup. Put these on hardware you control, where you pay once and they earn their keep for years. This is where self hosting quietly saves the most and nobody notices, because nothing dramatic happens, it just keeps working and stops costing rent.
Rent the spiky peaks and the critical-uptime jobs. Public websites, bursty compute, anything where someone else's redundancy beats yours. Pay while it runs, scale it down when it doesn't. This is the cloud doing what it's genuinely best at.
Keep your data portable. Whatever you hand to a provider, know what it costs to get back and keep a copy you control. Portability is the thing that keeps the relationship honest. For how I think about owning the core outright, see my case for self-hosting the parts that matter.
Never rent your dependence. This is the one that isn't about money. Renting compute is fine. Renting your ability to operate is not. If one provider tripling its price, going dark for a day, or closing your account would take your business down with it, that's not a vendor, it's a single point of failure you're paying rent on forever.

What "the right answer" actually looks like

A well-built setup isn't all-cloud or all-metal, it's deliberately split. The steady core runs on gear you own, already paid for, sipping power in the corner. The spiky and the must-never-fail bits run in the cloud, billed only when they're working. Your data stays portable, so no single provider can quietly become a cage. Set up like that, "should I use the cloud?" stops being a religious argument and becomes a per-workload question with an obvious answer each time. The cloud is a brilliant tool. It's just not the whole toolbox, and it was never meant to be the answer to everything. Own what's steady, rent what's spiky, and keep one foot on ground you control. That's the same principle behind running your own local AI on hardware you own, and it's the through-line in why I built things the way I did.

Self hosting vs cloud: common questions

Self hosting vs cloud: which is cheaper?: It depends on how your load behaves, not on which is cheaper in general. For steady work that runs all day every day, self hosting is usually far cheaper over a few years, the cloud charges rent around the clock for a machine you could buy once. For spiky or occasional work that sits idle most of the time, the cloud wins easily, because you only pay while it runs. The mistake is paying cloud rental prices for a steady, always-on workload: that's renting a flat you never leave. Map your load first, then pick the model that fits it.
When should a small business self host instead of using the cloud?: Self host the steady core, file storage, internal tools, an always-on database, archival backup. Those run constantly and their cost is predictable, so a box you own beats a meter that never stops. Stay in the cloud for the spiky and the critical-uptime jobs: bursty compute, a website that must never go down, anything where someone else's redundancy genuinely beats yours. Most small businesses are best on a hybrid: own what's steady, rent what's spiky, and never let one provider's price rise or outage hold the whole business hostage.
What are cloud egress fees and why do they matter?: Egress fees are what a provider charges to move your own data out of their platform. Storing is cheap and getting data in is free, but pulling large amounts back out costs real money, and that's deliberate. The more you keep there, the more expensive it gets to leave, which is how a convenient service turns into a dependence you can't easily walk away from. Before you commit serious data anywhere, check the cost of a full export. If leaving is expensive, you don't own your data, you're renting access to it.
Is self hosting practical on the NBN in Australia?: For internal use, absolutely. For anything the public must reach, design around the NBN's asymmetry: most connections give plenty of download but single-digit-megabit upload, and a service you host serves outward, so it's capped by that weak upload. Inside your own network it's a non-issue. For a public-facing service, use a business plan with real upload, a small cloud front end that talks back to your box, or just keep the public part in the cloud and self host the rest. Don't push a busy public site out through a residential upload pipe.
What does "don't rent your dependence" mean?: It means don't let any single provider become something your business can't function or escape from. Renting compute is fine; renting your ability to operate is not. The test: if your main provider tripled its price, went down for a day, or shut your account, would you survive it? If the honest answer is no, you don't have a vendor, you have a dependence you're paying rent on forever. Own the parts you can't afford to lose control of, keep your data portable, and make sure you could move if you had to. You probably won't. Being able to is what keeps it honest.
What is a hybrid cloud setup?: A hybrid setup runs some workloads on infrastructure you own and some in the cloud, on purpose, split by what each does best. The steady, predictable, cost-sensitive work, storage, internal tools, always-on services, lives on hardware you control, already paid for. The spiky, bursty or uptime-critical work, public websites, occasional heavy compute, anything that benefits from someone else's redundancy, stays in the cloud, billed only while it runs. It's not a compromise. It's the answer most setups should land on: own the base load, rent the peaks, and keep one foot on ground you control.

Weighing up whether something belongs in the cloud or on a box you own? Happy to give you a straight read on it, no pitch, no upsell to a stack you don't need. Tell me what you're trying to run and I'll tell you honestly where I'd put it, even if the answer is "leave it where it is."