So this is not a spec-sheet review. It's what the UGREEN DXP4800 is like to live with when photo backup is the main thing you ask of it. Mine is the 8GB RAM model, and I put a single 16TB Toshiba enterprise drive in it to start with.

Setting it up

The short version: you can go from box to working photo backup in an evening without reading a manual. Drives slide in without tools, the UGOS system walks you through initialization, and the mobile app finds the NAS on your network and starts backing up the camera roll once you let it.

For a product category that used to assume you enjoyed configuring RAID levels, that's genuinely the hard part solved. The people this box is aimed at will never see a terminal, and nothing in the setup flow pushes them toward one.

The photo experience, which is the point

This is where the DXP4800 earned its keep. The Photos app does the things you'd hope: albums, a timeline, and automatic backup from the phone in the background. What surprised me was the speed — browsing the library from my phone feels close to browsing photos stored on the phone itself. Thumbnails load fast enough that you stop noticing there's a network in between, and that matters more than any listed feature, because a photo library that feels slow is a photo library nobody opens.

Full-size photos leave the phone, space comes back, and the pictures are still one tap away. That was the promise, and it holds.

The mistake that cost me 268GB

One honest warning from my own use. The scheduled automatic backup never gave me a single duplicate. But early on I also did big one-time imports by hand — dumping an old phone's library onto the NAS in one go, then later doing something similar again. Those manual dumps overlapped with what the app had already backed up, and by the time I audited the library I had about 268GB of duplicates sitting on the drive.

The lesson is boring but real: pick one pipeline and let it run. Let the app do its scheduled backup, and treat manual bulk imports as a one-time migration you do once, carefully, not a habit. The NAS won't stop you from importing the same photos twice — cleaning that up afterwards is your problem, and at hundreds of gigabytes it's a real chore.

Remote access

Away from home, the UGREEN app reaches the NAS through the company's ug.link relay, and for photos on the go it has been fine — no router settings, no fixed IP, it just works. If you ever outgrow it and want your own domain in front of services on the NAS, that's solvable for free too, and I wrote up exactly how I did it with Cloudflare Tunnel.

What I'd push back on

Two things, one small and one structural.

The small one: the box invites a second drive, and you should budget for it sooner than you think. A single 16TB drive holds everything but is also a single point of failure, and "all our family photos" is exactly the data you don't want on one disk. Mirroring was always my plan; the review unit of one drive is a starting point, not the destination.

The structural one: UGOS is friendly precisely because it's closed. As long as you stay inside the official apps, everything is smooth. The moment you want more — run your own service, schedule your own tasks, use Docker from the command line — you find that your user can't touch most of the machine. There are ways through, and I wrote them up, but be clear about what you're buying: an appliance first, a Linux box a distant second.

Who it's for

If your problem is "our photos live on phones and nowhere else," the DXP4800 solves it well, and the solved version is pleasant to use daily. Buy it, put two mirrored drives in it, turn on the app's automatic backup, and resist the urge to hand-import things twice.

If your problem is "I want a small home server that happens to have disks," look carefully at the UGOS section above first. It can be that, I made it be that, but the OS will fight you politely the whole way.

No affiliate links in this review — I bought this unit myself, and this site currently earns nothing from any brand mentioned. If that ever changes, it will be disclosed here first.

Cloudflare Tunnel goes around all of it. Nothing at your house listens for incoming connections. Instead, a small program on your machine dials out to Cloudflare and keeps that connection open. When someone visits your domain, the traffic hits Cloudflare first, then rides back down that same connection into your house. Your firewall stays shut. Your ISP never has to cooperate.

It's free, and the HTTPS certificate is included.

What you need

• A domain, with its nameservers pointed at Cloudflare (the free plan is fine)
• Any machine at home that stays on: a NAS, a mini PC, a Raspberry Pi
• A service already running on that machine, reachable at http://localhost:<port> from the machine itself

That last point matters more than it looks. Get your service working locally first. If curl http://localhost:3000 doesn't return your page while you're sitting on that machine, the tunnel can't help you. It only carries traffic; it doesn't fix a service that isn't running.

The mental model

Three pieces have to line up. Mixing them up is where most of the confusion comes from, so here they are:

One tunnel can carry many hostnames. So one connector on your NAS can publish a dozen services on a dozen subdomains. What one tunnel can't do is span two machines.

Create the tunnel

In the Cloudflare dashboard, go to Zero Trust → Networks → Tunnels and create a tunnel (Cloudflare's own docs cover the same steps in more detail). Name it after the machine, not the app. You'll add more apps later, and a tunnel called "jellyfin" running six other things gets confusing fast.

Cloudflare hands you a token. Treat it like a password — anyone who has it can publish services onto your domain.

This is the "remotely managed" style of tunnel, where the routing config lives in the dashboard instead of a local config.yml. For a home setup that's the right default. There's no config file to lose, and nothing to re-edit when you add a hostname later. One trade-off worth knowing: the dashboard is now the source of truth. When you're wondering "why does this hostname point there?", the answer is never in a file on your machine.

Run the connector

If you have Docker:

docker run -d --name cloudflared --restart unless-stopped \
  --network host \
  cloudflare/cloudflared:latest tunnel --no-autoupdate run --token <YOUR_TOKEN>

--network host matters. The connector needs to reach services running on the host itself. Inside a normal bridge network, localhost means the container — not your machine — and nothing will connect.

If you don't have Docker, or your NAS won't let your user anywhere near it, that's fine too, because cloudflared is just a single file (grab the right build from the releases page) with no dependencies:

# pick the build matching your architecture
curl -L -o cloudflared \
  https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64
chmod +x cloudflared
nohup ./cloudflared tunnel --no-autoupdate run --token <YOUR_TOKEN> > cloudflared.log 2>&1 &

I want to say this plainly, because a lot of NAS tutorials treat Docker as a requirement: it isn't. All the container really buys you is a restart policy and log rotation, so on a locked-down box where you can't reach the Docker socket, the bare binary isn't a fallback at all — it's the shorter path. I hit exactly that wall on a UGREEN NAS, and that guide walks through it.

Give it a few seconds and the dashboard should show the connector as healthy.

Publish a hostname

Add a public hostname to the tunnel: subdomain app, your domain, and a service URL of http://localhost:3000.

Use http://, not https://. This is the one that gets everybody, including me. Your local service is almost certainly speaking plain HTTP with no certificate. Tell Cloudflare to reach it over https:// and the TLS handshake fails, so every request comes back as 502 Bad Gateway — with nothing in the error hinting that the protocol scheme is the problem. Your visitors still get real HTTPS. Encryption ends at Cloudflare's edge, and the hop from there into your house runs inside the tunnel.

The DNS record gets created for you. There's nothing to add by hand.

Check that it actually works

curl -sI https://app.example.com | head -3

A 200 means the whole chain works. If you get a 502, check in this order:

1. Does curl http://localhost:3000 work on the machine itself? If not, the problem was never the tunnel.
2. Is the service URL http:// and not https://?
3. Is the port right? A service bound to 127.0.0.1 while the connector runs in a bridge network is the same failure wearing a different hat.

A 530 or 1033 error means the tunnel itself is down. Check that the connector process is actually running — not just that you started it once.

Make it survive a reboot

A tunnel that dies when the power flickers is a demo, not infrastructure. With Docker, --restart unless-stopped handles it. Without Docker, use whatever your system gives you: systemd on a normal Linux box, or the scheduled-task UI on a NAS that has locked cron away.

Then actually reboot and watch it come back, because "it should come back" and "it came back" are different claims. The test takes five minutes, and it saves you from finding out the hard way during a power cut while you're traveling.

What this doesn't solve

Your site is now exactly as available as your house. Cloudflare doesn't cache HTML by default, so nearly every request travels back to your machine, which means a power cut, an ISP outage, or someone unplugging the wrong thing while vacuuming takes the site down with it. For a personal project that's a fair trade. For anything where downtime costs money, it's a real limit, and no tunnel setting changes it.

One hard number to know before you lean on it: requests through Cloudflare's free plan are capped at 100 MB of upload per request, and a tunnel can't opt out. Browsing, streaming, and dashboards will never notice it, but uploading your phone's camera roll to your own Immich or Nextcloud hits it immediately, unless the app splits uploads into smaller chunks. Check that before you promise yourself off-cloud photo backup through a tunnel.

And nothing here controls who gets in. A public hostname is public. If you're exposing something that was never meant to face the internet — a media server's admin panel, a database UI — put Cloudflare Access in front of it before you point the world at it.

When it's worth paying

Free covers more than people expect here: unlimited tunnels, unlimited hostnames, the certificate, and enough bandwidth that a content site will never notice a limit. For publishing services from home, there's genuinely nothing to buy.

The point where money starts to make sense isn't traffic, it's availability. If "what happens when the power goes out at home?" stops being an acceptable question, no tunnel feature fixes that — the fix is moving the service into someone else's building, which means a cheap VPS. I've written a separate guide on when free self-hosting actually runs out, because that's a different decision, made for a different reason, and it's worth making on purpose instead of drifting into it.

Here is the actual timeline, why it happened, and — more usefully — the pattern that lets you predict which free tier dies next.

The casualty list

Heroku, November 2022. The original free PaaS, the one every bootcamp taught, ended free dynos and free Postgres outright. Every "deploy your first app free on Heroku" tutorial on the internet became a museum piece overnight.

Railway, July 2023. Positioned as the Heroku successor, then cut its free plan citing crypto-mining abuse. What remains is a one-time trial credit and a token $1/month of usage — enough to prove your account works, not enough to run anything.

PlanetScale, April 2024. The serverless MySQL darling removed its Hobby tier entirely, giving existing free databases weeks to pay or migrate. It remains a paid-only product today.

Fly.io, October 2024. New accounts lost the free allowances. The trial for a new user is now measured in hours, and a card is required for everyone.

AWS, July 2025. The famous "12 months free" EC2 for new accounts was replaced by a credit-based plan that expires in months and then closes the account. The always-free serverless pieces (Lambda, DynamoDB) survived; the free VM did not.

Netlify, September 2025. New accounts moved to a credit system whose effective bandwidth is a fraction of the old 100 GB. The one mercy: it is a hard cap, so it stops rather than bills.

Koyeb, February 2026. Acquired by Mistral AI and immediately closed free signups. A free tier can end not because the model failed, but because the company got bought for its hardware.

Render, April 2026. Kept its free web services but cut free bandwidth from 100 GB to 5 GB per month. The tier survives; its usefulness for anything with an audience does not.

Oracle Cloud, June 2026. The most generous free VM on the market — 4 ARM cores and 24 GB of RAM — was quietly halved to 2 cores and 12 GB. Still the biggest free compute you can get; also a reminder that even the outlier obeys gravity.

The survivor list

Shorter, and worth memorising:

• Cloudflare — Pages, Workers, R2, and Tunnel. Unmetered static bandwidth, free egress from object storage, no card required. The core limits have not shrunk in years.
• GitHub Pages — unchanged for a decade, within its non-commercial terms.
• Google Cloud Run and the e2-micro VM — Google's always-free tier has held steady, though both require a card and can bill past the free line.
• Supabase, Neon, Turso — the free database tier is alive and well, card-free, with suspend-when-idle as the trade instead of money.

The pattern

Look at the two lists and the structural difference jumps out. The casualties were all cases where your free usage cost the provider real marginal money — compute hours, egress bandwidth, storage on someone else's cloud. Free was a customer-acquisition expense, funded by venture capital, and it ended when the funding climate did.

The survivors are cases where your free usage costs the provider almost nothing, or you are not the customer at all. Cloudflare runs its own network; serving your static site through capacity it already owns is nearly free, and every free user strengthens the network effect it sells to enterprises. GitHub Pages is a rounding error on Microsoft's developer-ecosystem spend. Google's always-free tier is a funnel into a card-on-file billing relationship.

So the test for any free tier is one question: why is this free? If the honest answer is "to acquire me as a paying customer later, while burning investor money on my bandwidth" — build on it expecting eviction. If the answer is "my usage is nearly free to them" or "I am the marketing" — it will probably outlive the tutorial you learned it from.

What this means in practice

Date every tutorial. Anything about free hosting older than a year is unverified until you have looked at the current pricing page. This article included.

Keep the exit cheap. The real cost of a free tier dying is not money, it is migration under deadline. Prefer boring, portable shapes — static files, a SQLite or Postgres dump, a Docker image — over anything that only exists inside one platform's proprietary config. The people burned worst by the Heroku and PlanetScale shutdowns were the ones whose setup could not be described without naming the vendor.

Let the retreat push you home. A machine you own has no free tier to lose. The NAS or mini PC that was a toy in 2021 is, after four years of cuts, quietly the most stable "free hosting" there is — nobody can revoke it, halve it, or get acquired out from under it. That is not nostalgia for self-hosting; it is just where the trend line points.

Free hosting is not dead. But the era when you could assume a free tier was a permanent fact of the landscape ended somewhere around 2023, and building anything meant to last means planning for the day the email arrives.

The same shape of story exists for most metered platforms: the startup that burned $72,000 on Google Cloud in a few hours through a runaway loop, the Firebase apps rung up for thousands overnight by scripted traffic, the AWS bills generated by strangers hammering a bucket the owner thought was idle. Different products, one cause: the platform's worst case was money, and there was no ceiling.

The three kinds of "free"

Every hosting free tier belongs to one of three billing shapes, and the shape matters more than the numbers on the pricing page.

1. Free with no card and no meter. The platform does not have your payment details, so its only possible response to excess usage is refusal: an error, a throttle, a suspended service. Cloudflare's free plan, GitHub Pages, Supabase, Neon, Turso, and Render's free tier all work this way. The worst case is downtime.

2. Free with a hard cap. There may be a card on file, but spending stops at a limit by design. Netlify's post-2025 credit system is this — one useful thing to come out of that invoice. The worst case is downtime at the end of the month.

3. A free allowance on top of a metered account. Firebase's Blaze plan, Google Cloud, AWS. The free tier is a discount, not a boundary; past it, every request converts to money at market rate, without limit, at machine speed. The worst case is debt, and the size of the worst case is set by your attacker, not by you.

Nothing in category three is dangerous when idle. It becomes dangerous at the exact moment something unexpected happens — a traffic spike, a scraper, a bug in your own retry logic — which is precisely the moment you are not watching.

Why budget alerts do not save you

Every metered cloud offers "budget alerts", and the name does a lot of quiet misleading. An alert is an email. It does not stop, throttle, or cap anything. Google Cloud's own documentation is plain that a budget does not prevent spending; it notifies you about it. The $72,000 Google Cloud incident took under two hours end to end. Alert emails were sent. They were read the next morning.

Some platforms let you build a real kill switch — on Google Cloud you can wire a budget notification to a small function that detaches the billing account, taking your project down but ending the bleeding. That works, and if you keep anything on a metered cloud you should install it. But notice what it is: a do-it-yourself circuit breaker for a product that declined to include one.

The decision rule

Before putting anything on a platform, ask one question: what is the worst thing that happens if a stranger sends this service a million times more traffic than I expect?

If the answer is "it goes down" — fine. Downtime on a hobby project costs nothing. This is the correct default for anything personal: sites, dashboards, bots, experiments. It is also, not coincidentally, what you get from a machine at home behind a free tunnel: your worst case is that your own hardware is busy.

If the answer is "I get billed" — the platform needs to clear a much higher bar, and you need three things in place from day one: a spending cap if it exists, a real kill switch if it does not, and a genuine reason the capped alternatives will not do. "The tutorial used it" is not such a reason.

Where that leaves a home server

A self-hosted box has plenty of real risks — power, disk failure, your own attention span — and this site does not pretend otherwise. But it is worth naming the risk it does not have. There is no meter. A flood of abuse against a service in your house saturates your connection, annoys you, and ends. It cannot compound at $0.55 per gigabyte while you sleep.

Pair that with a front door whose free plan also cannot bill you — a tunnel through an unmetered edge — and the entire attack-cost equation belongs to someone else's balance sheet. If you're weighing that trade, the honest version of when home hosting stops being enough is its own article. That combination, not raw performance, is the strongest argument for the home-server-plus-free-edge setup this site keeps coming back to: it is the only architecture where the answer to "what is the worst case?" is fully known in advance.

Money buys availability, and sometimes availability is worth buying. But debt should require your signature. Choose platforms where it does.

It does not. UGOS reserves a lot for its own management layer, and the account you SSH in with is not the account that owns the system. Every one of the four standard moves fails, each in a slightly different way, and none of the error messages tell you what to do instead.

Here is what actually works, and what each wall looks like when you hit it. Almost every guide for this class of appliance is written for Synology, where the answers are different. This one is written from UGOS.

Wall 1: your SSH user cannot use Docker

You will find Docker installed and immediately discover it is not yours to use:

$ docker ps
permission denied while trying to connect to the Docker daemon socket
at unix:///var/run/docker.sock: connect: permission denied

The usual fix is sudo usermod -aG docker $USER. That fails too, because your account has no sudo, and UGOS does not offer a way to grant either one. Docker on this appliance is reachable through the desktop UI app and through control panels like 1Panel, but not from your shell.

What to do instead: skip Docker. This sounds like a downgrade and mostly is not. A container buys you a restart policy, log rotation, and dependency isolation. For a single service with no system dependencies, you can get the first two by other means and do not need the third.

Everything below assumes a plain host process.

Wall 2: your runtime's installer needs unzip, which is absent

Most modern runtimes install with a one-liner that pipes a script into your shell. On UGOS that script gets some distance and then dies, because the archive it downloads is a zip and there is no unzip on the system. There is no apt either — this is an appliance, not a distro.

What to do instead: unpack it on your own machine and copy the binary over. Most runtimes ship a single static binary inside that archive; the installer script is a convenience, not a requirement.

# on your own machine
curl -L -o runtime.zip https://example.com/runtime-linux-x64.zip
unzip runtime.zip
# stream the binary over SSH into place
cat runtime-linux-x64/bin/runtime \
  | ssh user@nas 'mkdir -p ~/bin && cat > ~/bin/runtime && chmod +x ~/bin/runtime'

Then add ~/bin to your PATH in ~/.profile. From here on the runtime behaves completely normally — the only thing missing was the unpacking tool.

The same trick works for any single-binary tool you need on the box.

Wall 3: SSH is not exposed, so plan how you reach the machine

Port 22 is not open to the internet, and it should stay that way. When you are at home this is a non-issue. When you are not, you need a private path in.

The clean answer is a mesh VPN — Tailscale or equivalent — which gives the NAS a stable private address reachable from your laptop anywhere, with no ports opened and no dynamic-DNS games. Install it, and ssh user@100.x.y.z works from a different continent.

Worth knowing before you need it: the UGOS app centre has no web terminal, and the "Terminal" entry in the control panel is only an on/off switch for the SSH service, not a shell. If you lose your private path while away from home, your remaining options are the control panel's scheduled-task feature — which can run a script, so it doubles as a crude remote-execution channel — or waiting until you are back on the LAN. Set the VPN up before you travel, not after.

Wall 4: cron refuses you, and nohup alone is not enough

Two separate problems, usually discovered together.

First, starting a process over SSH and disconnecting kills it unless you detach it properly:

setsid nohup ~/bin/runtime server.js > ~/logs/app.log 2>&1 &

nohup alone survives the hangup signal in most cases; setsid also detaches the process from the terminal's session, which is what you actually want for something meant to outlive your shell.

Second, the obvious way to start it at boot is not available:

$ crontab -e
/var/spool/cron: Permission denied

There is no user crontab, and no systemctl --user either.

What to do instead: use the control panel's scheduled tasks. UGOS exposes a task scheduler in its web UI with a run-at-startup trigger, and it will run a shell script as your user. Point it at a small launcher script rather than at the command directly, so you can change how the service starts without going back into the UI:

#!/bin/sh
# ~/apps/myapp/start.sh — kill any previous instance, then start fresh
pkill -f 'runtime server.js'
sleep 1
cd ~/apps/myapp || exit 1
setsid nohup ~/bin/runtime server.js > ~/logs/app.log 2>&1 &

The same script is your deploy step and your restart step, which is one fewer thing to remember.

Deploying updates: tar over SSH

rsync is not present and scp is unreliable here. What works is streaming a tar through the SSH connection:

tar czf - --exclude=node_modules --exclude=data . \
  | ssh user@nas 'mkdir -p ~/apps/myapp && tar xzf - -C ~/apps/myapp'
ssh user@nas '~/apps/myapp/start.sh'

Exclude your data directory explicitly, every time. The one deploy where you forget is the one that overwrites your database with an empty copy from your laptop.

Verify the part everyone skips

Restarting the service proves the service works. It does not prove the thing you actually care about, which is that the NAS comes back on its own after losing power.

So test it: reboot the NAS from the control panel, wait, and check that the service answers without you touching anything.

curl -sI http://<nas-address>:<port>/ | head -1

"It should come back" and "it came back" are different claims. The gap between them is usually a scheduled task that was saved but never enabled, and you would rather find that out now than during a power cut while you are away.

What this gets you

A service running as your own user, started at boot by the appliance's own scheduler, deployed with one tar command, with no sudo, no Docker, and nothing installed system-wide. It is less elegant than a container and considerably less elegant than systemd, but it is entirely within what UGOS will let you do, and it stays working.

When it's worth paying

Nothing in this article costs money, and for running services at home the free path genuinely goes the whole distance. The appliance is already bought, the software is free, and the constraints are annoying rather than limiting.

The honest limit is not money, it is what a box in your house can promise. One power supply, one internet connection, and no maintenance window that is not your own evening. That is fine for a personal service and fine for a site like this one. The moment something needs to be up while you are asleep, travelling, or moving house, the fix is not a better startup script — it is a machine in a building with a generator, which is where a cheap VPS starts to make sense. I've written about how to tell when you've actually reached that point, because deciding it deliberately beats discovering it during an outage.

Both skip the only question that matters: what specifically does free fail to provide, and does your project need that thing?

Here is that question answered concretely. Nothing below is an argument for spending money — most home setups genuinely never need to. It is an argument for knowing in advance which line you will eventually cross, so that when you cross it you recognise it instead of blaming your own configuration.

What free actually covers

More than people expect, and it is worth being precise, because vague gratitude toward free tiers is how people end up paying for things they already had.

Getting online at all. A tunnel service publishes a machine at home to the public internet with no public IP address, no forwarded ports, and no static address. This is fully solved and it is free. If your reason for considering a VPS is "I cannot get in from outside", you do not need a VPS.

HTTPS. Certificates are free and automatic, both through tunnels and through Let's Encrypt directly. This has not been a reason to pay for anything in years.

Bandwidth, for anything text-shaped. A content site, a personal dashboard, a git remote, an API for your own use: the traffic is negligible. Free tiers are not going to notice you.

Compute. A four-bay NAS or a second-hand mini PC will out-specify a $5 VPS on every axis — more cores, far more RAM, vastly more disk. Even a locked-down consumer NAS can run a long-lived service once you know the walls. You are not short of compute at home. You are short of something else.

What free cannot promise

Four things, and they are all the same shape: they are properties of the building, not the software.

Power. One supply, no generator, no UPS unless you bought one. A cut means the site is down until you are physically present or the scheduled task does its job at boot — assuming the boot itself succeeds.

Connectivity. One residential line. Your ISP does maintenance whenever it likes and owes you nothing. Upload is asymmetric and modest, which does not matter for text and matters immediately for video or large downloads.

Presence. Something that needs a hand — a stuck process, a full disk, a failed drive — needs your hand, in that room. This is the constraint people underestimate most, because it is invisible until you are away.

A separate failure domain. Your backups, your tunnel, your monitoring and the thing being monitored all live on one box in one room. When that room has a problem, you lose the ability to observe the problem at the same moment you gain the problem.

Notice what is not on this list: performance, reliability of the hardware, software capability, or professionalism. Those are not what you would be buying.

The four signals you have outgrown free

Not thresholds you should aim for. Signals to watch for, in rough order of how often they actually arrive.

1. Someone other than you is depending on uptime. The moment a real user, a client, or a paying customer is affected by an outage, "I will fix it when I get home" stops being an acceptable answer. This is the signal that arrives first and matters most, and it has nothing to do with traffic volume.

2. You are about to be away. Travel, a move, a hospital stay. A setup that requires your physical presence is fine right up until it does not, and this one you can see coming.

3. Your uploads are the bottleneck. If you are serving video, large binaries, or an image-heavy site to an audience in another region, residential upload is the wall — and no configuration change moves it.

4. Your backups are not somewhere else. If the answer to "what if the NAS is stolen or the flat floods?" is a shrug, the thing you need is not a VPS, it is off-site storage. That is a cheaper purchase than a server and it is more urgent than one. Do not conflate the two.

If none of those apply, you are done. Stay free. The rest of this article is not for you yet.

What to buy, in the right order

Assuming a signal has actually arrived, the mistake is to buy a server first. Spend in this order:

1. Off-site backups. Cheapest, highest value, and it addresses signal 4 completely. Object storage costs a few dollars a month for a personal-sized dataset.
2. A UPS. Addresses brief power cuts, which are most power cuts. A one-time purchase, no subscription, and it also protects the disks you already own.
3. External monitoring. A free uptime checker that lives outside your house tells you the site is down before your readers do. It fixes the observability half of signal 1 for nothing.
4. A small VPS. Only now, and only for the specific thing that needs to be in a different building. Frequently that is not the whole service — it can be just the tunnel endpoint, or a mirror of the static site, while the heavy storage stays at home.

Steps 1 to 3 handle most of what people buy a VPS to solve, at a fraction of the cost. If you skip them and buy the server, you will own a server and still have your original problem.

A note on what this site has not tested

This article deliberately names no VPS provider. I run at home, and I have not personally put this site's workload on a paid host, so any provider comparison from me would be repackaged marketing copy rather than experience. That would be worth less than nothing to you.

When that changes, the write-up will be of an actual migration with actual numbers, and it will say what went wrong.

When it's worth paying

Free is not a compromise for self-hosting at home. It is the correct default, and it covers getting online, encryption, bandwidth, and compute completely.

What money buys is not capability. It is someone else's building — their generator, their redundant connection, their staff at 3am. That is the entire transaction. It becomes worth it the moment your own presence stops being a reasonable dependency, and not one day before. Until then, the cheapest and most honest infrastructure decision available to you is the one you are already running.