Hosting vs Self-Hosting: The Full Cost Model We Actually Use

Someone sent us a spreadsheet last month comparing a hosting quote at $0.068/kWh all-in against their own site's $0.041/kWh industrial rate. On paper, self-hosting won by a mile. What the spreadsheet didn't have a line for: who drives out to swap a hashboard when it fails on a Sunday, and how many hours of downtime that adds up to over a year. That's the line that actually decides most of these calls.

It's not fee vs rate, it's total cost under stress

The hosting vs self-hosting question usually gets framed as a simple rate comparison. In practice, the number that decides it is uptime variance and how fast you can respond when something breaks — not just what you pay per kilowatt-hour on a good day.

The cost buckets people forget

• Direct energy cost: your real kWh rate including demand charges and delivery fees, not just the headline generation rate.
• Downtime cost: expected lost revenue from outages and the slower, unstable stretches before and after a fix. This is usually the single biggest number people leave out entirely.
• Maintenance cost: repair labor, spare hashboards and PSUs on hand, and whose time gets burned doing the work.
• Infrastructure cost: cooling, networking, power distribution, and whatever monitoring stack tells you something's wrong before a customer or a missed block does.
• Governance cost: the hours spent managing a hosting contract, chasing an SLA, or handling compliance paperwork — real time, even if it never shows up on a power bill.

Read the hosting contract like you mean it

If you're leaning hosted, the SLA is where the real value lives or dies. Look past the headline uptime percentage and check what actually triggers a credit — some contracts only count full-facility outages, not the slow, degraded stretches where half your rack is offline for two days while a part ships in. Ask how fast they'll actually swap a failed board, not how fast the contract says they will, and if you can, talk to another client hosted at the same site before you sign.

Stress-test it before you sign anything

1. Build a base case using conservative BTC price and difficulty assumptions — not the best week of the last twelve months.
2. Push it: add 10-20% more difficulty and knock 5-10% off realized uptime, since both self-hosted and hosted sites run below their advertised uptime more often than either side likes to admit.
3. Compare how much margin each model loses under that stress, not just under the base case.
4. Go with whichever option still pencils out under the stress case. The best-case number is basically marketing at that point.

When hosting wins

Hosting tends to win when you need predictable uptime and fast incident response without building an on-site team, especially while you're still scaling and don't want operational complexity competing with growth.

When self-hosting wins

Self-hosting tends to win when you've got genuinely cheap, reliable power, a technical team that can actually fix things at 2am, and enough scale that the fixed cost of building real ops capability gets spread thin enough to be worth it.

If your model skips downtime and maintenance variability, whichever option you pick is probably going to look better on paper than it performs in the first bad month.

Honest caveat: we've watched self-hosted setups with cheap power still lose to hosted setups on realized margin, purely because a single extended outage wiped out six months of the electricity savings. Cheap power only pays off if you can also keep the lights on. Run your own numbers, including a bad month, through our profitability calculator before you commit to either path.