What Is Self-Hosting? A Real Answer, With a Real $4 Server
Hasan Aboul Hasan
Published 2026-08-11
Self-hosting means running the software you rely on, on a server you control, instead of paying a company to run it for you. That is the whole definition. The interesting part is what it buys you, what it honestly costs, and how small the first step actually is. To show that last part, I took a fresh $4/mo server from empty to two live services in under 15 minutes of work, and every number and screenshot on this page came from that run.
Self-hosting is not a rack of servers in a basement. It is usually one small rented VPS, Docker, and open-source apps that replace subscriptions. People do it for three reasons: cost (my own managed-cloud bills added up to ~$8,400/yr before I consolidated), control, and privacy. The honest price is attention, not maintenance: I have measured a real upgrade at 16 seconds of downtime. Below: what the term actually means (it has two meanings, which is why Google's #1 result is a confusion thread), why people do it, what you need, and a real first app going live on a $4/mo box.
I run my business this way. This site, my analytics, my automations, and my email marketing all live on servers I control, and that stack is what my Self Hosting 2.0 course teaches start to finish. This page is the entry point: the concept, then proof.
New to servers? The jargon on this page, translated
- VPS
- Virtual Private Server. A slice of a real server you rent for a few dollars a month. Yours from the operating system up, reachable from anywhere.
- Docker
- A tool that runs each app in its own sealed box (a container), with everything the app needs packed inside. One command per app.
- SSH
- The encrypted remote terminal you manage a server through. With key-only login, only the machine holding your private key gets in.
- Firewall (ufw)
- The doorman that only opens the ports you name. Everything else gets silence.
- Port
- A numbered door on your server. SSH answers behind 22, websites behind 80 and 443, our demo app behind 3001.
- Open source
- Software whose code is public and free to run. The engine of self-hosting: most SaaS tools have an open-source equivalent.
What self-hosting actually means
Self-hosting means running the software you rely on, on a server you control, instead of using a company's hosted service. Analytics without Google Analytics. Automations without Zapier. File sync without Dropbox. The apps are usually open source, the server is usually a small rented VPS, and the total bill is usually a few dollars a month.
Here is the part nobody tells you, and the reason the top Google result for this exact question is a Reddit thread titled "Confused about the definition of self hosting". The term has two common meanings, plus an old third one, and people talk past each other:
The r/selfhosted meaning, and what this page is about. You control the operating system and everything above it: the apps, the data, the updates.
The blogging meaning: WordPress.org software on rented shared hosting, as opposed to WordPress.com. You control the site, the host controls the server. Real, but a much smaller claim.
Old computer science term: a compiler that can compile itself. If you landed here for that one, this is not your page.
The follow-up argument is always "does a rented VPS even count, if you do not own the metal?" I think that argument misses the point. Control over the physical machine is not the lever. Control over the stack is: the operating system, the apps, the data, and the ability to pack it all up and move it anywhere. Rent the metal, own the stack. Every practical benefit on this page comes from that, and by that standard a $4/mo VPS counts completely.
Why people do it: three reasons, with receipts
Every "what is self-hosting" page lists cost, control, and privacy. What they never show is a number. So here are mine.
Cost: the bill you never total
Managed cloud services look cheap one at a time. A database here, a hosting plan there, an analytics tool, an email tool. I paid those bills for years without adding them up. When I finally did, they came to about $8,400 a year, roughly $700 a month, for things one dedicated server could run. I consolidated all of it onto a single VPS running Coolify and wrote the whole story in my Coolify starter guide. The savings were not the surprise. The surprise was that no single bill ever looked worth questioning.
Control: the tool no SaaS sells
The second reason is quieter and, in my experience, the one that keeps you self-hosting after the novelty fades. A subscription tool does what its vendor decided it does, at the plan tier you pay for, with the limits they chose. Your own server does whatever you can describe. I replaced roughly $200/mo of subscription tools, brand tracking, keyword rank tracking, and YouTube comment management, with scheduled Python scripts on PyRunner, running on a ~$5/mo VPS. No plan limits, no per-seat pricing, no feature voting. That system is not better because it is cheaper. It is better because nobody sells it.
Privacy: your data on your box
The third reason needs the least explanation. A self-hosted app's data sits in a folder on your server. Nobody mines it, nobody trains on it, nobody sunsets the product under you. For some apps this barely matters. For your photos, your notes, your email list, your business analytics, it starts to matter a lot. I will not preach it. If this reason speaks to you, you already know.
The honest cost
Now the other column, because a page like this that only sells the upside is an ad, not an answer.
Maintenance is measured in seconds, not weekends. The standard argument against self-hosting is that you become the person doing the upgrades. So I timed one, on a self-hosted analytics stack: pulling the new version and restarting took 16 seconds of downtime, migrations ran themselves, and the app ships about two releases a year. That is roughly half a minute of downtime annually. The full measurement is in the Plausible guide.
Security is real, but it is a checklist, not a talent. Any public server gets scanned constantly. In an earlier experiment I left a brand-new server watching its own logs: the first uninvited SSH login attempt arrived 2 minutes 35 seconds after boot, and 1,820 attempts followed in 16 hours. None succeeded, because the basics were in place: key-only SSH and a firewall. The attacks are background radiation. A locked box shrugs them off, and you will watch this page's demo server get locked in one step below.
The real currency is attention. When your self-hosted app breaks, you are the support team. In practice that means: run boring, popular apps; keep backups; do not self-host the thing your business dies without until you know what you are doing. That is the honest trade. You are swapping money for attention, at a rate that gets better as you learn.
What you actually need
The mental image that stops most people is a rack of humming hardware and a networking degree. Here is the actual shopping list for a first real setup:
| Thing | What it is | Real cost |
|---|---|---|
| A small VPS | A rented slice of a server. Any provider works; my VPS directory compares live prices. | $4–6/mo |
| Ubuntu | The Linux most guides (including all of mine) assume. Preinstalled by every VPS provider. | $0 |
| Docker | Runs each app in its own container. The install is one command and, on my demo box, 61 seconds. | $0 |
| An open-source app | The thing you actually wanted. Pick from the apps board. | $0 |
| ~30 minutes | For a first app, including wrong turns. The timed run below took less. | — |
What about hosting at home, on an old PC or a Raspberry Pi? It counts, it works, and it is cheaper per month. It also brings your home internet connection, your router settings, and your electricity bill into the project, and puts your experiments on the same network as your family's devices. In my experience the rented VPS is the better first move: a public IP address that just works, and if you break the box beyond repair, you delete it and boot a new one in a minute. Learn there, bring it home later if you want.
The proof: a first app live on a $4/mo server
Concept pages love to stay conceptual. Instead, here is the smallest real version of everything above, timed and screenshotted as I did it. The goal: a fresh server, locked down, running Uptime Kuma, an open-source app that watches your websites and tells you when they go down. It is the classic first self-hosted app: genuinely useful, one command to run, and it gives you a dashboard worth looking at.
Step 1: rent the smallest server that works
I created the cheapest droplet DigitalOcean sells: 1 virtual CPU, 512MB of RAM, 10GB of disk, $4.00/mo ($0.00595 per hour), with my SSH key added during creation. From clicking create to a working SSH login took 54 seconds. That is the entire "buy a server" step: less time than finding your wallet.
The 512MB of RAM is a deliberate choice, not a compromise. Part of the point of this example is finding out whether the smallest box on the menu can hold a real app. Watch the memory numbers as we go.
Step 2: lock the door before you furnish the room
Remember the 2-minutes-35-seconds number from above: scanners find every new public
server in minutes. So security comes first, and at this stage it is two facts and one
command. The two facts: because I gave the provider an SSH key, password login over SSH
is already off (I verified: sshd -T reports
passwordauthentication no), so the 1,820-attempts crowd is locked out
before it arrives. The one command: turn on the firewall, allowing only SSH, the web
port, and the app's port.
ufw allow OpenSSH ufw allow 80/tcp ufw allow 3001/tcp ufw --force enable
That is a beginner-grade lockdown, and for a demo box running one app it is honestly most of what matters. The full checklist, with each step measured against a live attack log, is in the VPS hardening guide.
Step 3: install Docker (61 seconds)
Docker is the one real prerequisite, and its official install script does everything:
curl -fsSL https://get.docker.com | sh
On my box this took 61 seconds and the Docker daemon settled at about
45MB of RAM. One honest gotcha I hit so you do not have to: on a brand-new
Ubuntu server, wait two minutes before running this. Ubuntu runs its own package updates
on first boot, and my first attempt died with
Could not get lock /var/lib/apt/lists/lock because the system's own updater
still held the package manager. Two minutes later the same command ran clean.
Step 4: one command, first app
This is the moment the whole page has been building to, and it is one line:
docker run -d --restart=always -p 3001:3001 \ -v uptime-kuma:/app/data --name uptime-kuma louislam/uptime-kuma:1
Docker downloads the app and starts it. On my box the download took 22 seconds and the app was answering in the browser 8 seconds after the container started. Here is the server's view, real output:
The whole install, as the server saw it
Real output from the demo droplet, 11 August 2026.
root@cf-what-is-self-hosting:~# docker run -d --restart=always -p 3001:3001 \ -v uptime-kuma:/app/data --name uptime-kuma louislam/uptime-kuma:1 Unable to find image 'louislam/uptime-kuma:1' locally 1: Pulling from louislam/uptime-kuma Status: Downloaded newer image for louislam/uptime-kuma:1 24b130f4698b9743f893cd911a13d4da6b2fb9e5f97a5dd49e81d5845bd7a279 root@cf-what-is-self-hosting:~# docker ps --format 'table {{.Names}}\t{{.Image}}\t{{.Status}}' NAMES IMAGE STATUS uptime-kuma louislam/uptime-kuma:1 Up 7 seconds (health: starting)
Open http://your-server-ip:3001 in a normal browser and the app is
simply there, asking you to create your admin account:
I created the account, added one monitor watching this very website, and two minutes later the dashboard was doing its job:
Step 5: the same box serves a website
Since "how do I host my own website" is half the reason people search this topic: the same server, with one more command, is also a web server. I dropped an HTML file into a folder and started nginx (a web server) in a second container:
docker run -d --restart=always -p 80:80 \ -v /opt/mysite:/usr/share/nginx/html:ro --name mysite nginx:alpine
Seven seconds later, port 80 was serving my page to the world:
Did the smallest server survive?
Two services are now running: a monitoring app checking a live website every minute, and a web server. Here is the memory story on the 512MB box, measured at each step:
Everything fits on the $4/mo server
RAM in use on the 512MB droplet (458MB usable), from free -m at each
step, measured after the first-boot system updates settled.
Uptime Kuma itself uses 88MB, nginx uses 3MB, and the whole stack sits at 318MB with 140MB to spare. Disk: 3.2GB of 10GB used. The smallest droplet on the menu holds a real app and a website with room left over. Heavier apps need more (the apps board lists per-app requirements), but the entry ticket really is $4.
What this actually cost
The demo server was destroyed after this run. One honest footnote before it went: I checked its SSH log expecting the usual bot traffic, and in this box's 63 minutes alive, zero uninvited login attempts arrived. The earlier server got its first in 2 minutes 35 seconds and 1,820 over 16 hours. Same provider, same region, different hour. The background radiation is real, but it comes in bursts, and you do not get to choose which kind of hour you boot into. Lock the door anyway.
Where to go from here
Everything above is the entry point. The path deeper, in the order I would actually walk it:
- Understand the two tools you just used. install Docker on Ubuntu properly, then put a reverse proxy in front so every app gets a real domain and HTTPS instead of an IP and a port number.
- Pick your second app. The self-hosted apps board is my running database of apps worth hosting. If you already pay for Zapier or Make, self-hosting n8n is the one with the clearest payback math.
- Graduate to a managed setup. When one-command-per-app stops scaling, Coolify gives you a dashboard over the same Docker fundamentals, deploys, domains, and HTTPS included. That is the stack I run in production.
- Harden it for real. The security checklist, each step verified against a live server's attack log.
Questions people actually ask
What is self-hosting in simple terms?
Running the software you rely on, on a server you control, instead of paying a company to run it for you. Rent a small server, install open-source apps, own your data and your bill. The difference between renting each tool and owning the workshop.
Can I host my own website?
Yes, and it is one of the easiest starts. In the worked example above, a $4/mo server served a live web page after one Docker command and about 10 minutes of total work. Add a domain and HTTPS with a reverse proxy and it is a real website.
Is self-hosting cheaper than paying for SaaS?
Often, but not automatically. One $4–6/mo server can replace several subscriptions, and the savings grow as you add apps to the same box. My own managed-cloud bills totaled about $8,400/yr before I consolidated them onto one server. But if you only need one cheap tool, the subscription may honestly be simpler. Self-hosting pays you back in proportion to how much you use it.
Is self-hosting hard to maintain?
Less than the horror stories say. A real upgrade I timed took 16 seconds of downtime, twice a year. The honest ongoing cost is attention: you are the one who notices when something breaks, and backups are your job.
Is it safe to put my own server on the internet?
With the basics done, yes. Public servers get scanned constantly (1,820 attempts in 16 hours on a server I measured), though it comes in bursts: the demo box above happened to draw zero in its hour alive. Key-only SSH, a firewall, and no unnecessary exposed services is the whole beginner checklist, and the demo box had all of it before its second minute.
Do I need my own hardware?
No. Renting a $4–6/mo VPS while owning everything from the OS up is the practical middle, and where I would start. Home hardware also counts and costs less monthly, but adds your ISP, router, and electricity to the project.
What should I self-host first?
Something small, visual, and harmless if it breaks: Uptime Kuma or a static website, exactly as in the example above. Save email servers and anything holding irreplaceable data for after you have backups and some scar tissue.
Related
This page is the first step of it. In Self Hosting 2.0 I take an empty VPS to a full stack you own: Coolify, real apps, backups, email, and security, in the order it should actually happen. 34 lessons, nothing skipped.
Get the free Vibe Engineering Blocks guide
The exact building blocks I use to ship real products with AI — yours as a free PDF.
Questions & Discussion
Ask a question about this guide →Have a question? Ask it in the community — it's tagged #guide and linked back here. Reading is open to everyone; posting needs a free account.
Loading questions…