How to Build a Homelab on a VPS

A homelab used to mean a rack of noisy servers in someone’s garage. In 2026 it means something much simpler: a handful of self-hosted apps that replace subscriptions, give you control over your own data, and teach you real infrastructure skills along the way. The self-hosting market is on track to reach $85.2 billion by 2034, growing about 18.5% a year, and most of that growth now comes from regular users rather than IT professionals.

This guide is not a ranking of VPS providers, and it is not a generic “how to set up a Linux server” walkthrough. It is a practical path from an empty VPS to a working personal cloud: reverse proxy, a starter set of self-hosted services, a link back to your home network, and backups you can actually trust. Follow the steps in order and by the end you will have a homelab that runs itself.

What Is a VPS Homelab and How Is It Different From a Home Server

A VPS homelab is a set of self-hosted services running on a rented virtual server instead of a physical machine sitting under your desk. The core idea is the same as a traditional homelab: you install open source software, you manage it yourself, and your data lives on infrastructure you control rather than a company’s servers.

The difference is what you don’t have. There is no local NAS with terabytes of spinning disks, no physical access to reboot a stuck machine by hand, and no direct line to smart home devices on your home network. What you get in exchange is a server that never sleeps, a public IP address, and a provider handling the hardware. Many experienced self-hosters end up running a hybrid setup: a VPS for anything that needs to face the internet, and a home machine for bulk storage. We will come back to that combination later in this guide.

Why Rent a VPS Instead of Running Everything at Home

A server sitting at home depends on things you don’t fully control. A power outage, an OS update that triggers a reboot, or a flaky home internet connection all take your services offline at the worst possible moment. If a service needs to answer requests at 2 a.m., a home machine is not a reliable place to run it.

The cost argument holds up too. A Raspberry Pi 4B with 8 GB of RAM costs around $115 upfront. At roughly $7.70 a month for a comparable VPS, it takes about 15 months to break even on the Pi, and the VPS runs a full x86 operating system with far more flexibility than ARM hardware. The subscription math is even more direct. A typical stack of SaaS tools, analytics, email marketing, a password manager, project management, can run $50 to $100 a month. The self-hosted equivalent of that same stack often runs comfortably on a $10 VPS. Google Photos illustrates the same pattern on the consumer side: a 2 TB plan costs about $120 a year, indefinitely, while a self-hosted photo library needs only modest ongoing storage costs.

There is also a growing privacy angle. More AI companies are training models on user data by default, and self-hosting simply removes your data from that pipeline. None of this requires expensive hardware. A VPS server with a few gigabytes of RAM and a clean Ubuntu image is enough to get a real homelab running the same day you provision it.

What You Need Before You Start

Before installing anything, make sure you have the basics in place:

• A VPS with root access, ideally running Ubuntu 24.04 LTS, the most documented base for self-hosted guides and troubleshooting.
• A domain name you control, with access to its DNS settings.
• An SSH client and basic comfort typing commands in a terminal.
• A rough idea of which services you actually want to run, so you don’t over-provision from day one.

Sizing the server correctly avoids two common problems: paying for resources you don’t use, or running out of RAM the moment you add a third container.

How Much VPS You Actually Need

Note: VPS storage is rarely the right place for a large media library. Treat local NVMe as fast, limited space for apps and databases, not as a substitute for a home NAS with several terabytes of disk.

Step 1: Prepare and Secure the Base Server

Before deploying a single service, spend twenty minutes locking down the server itself. This is not a full hardening guide, just the minimum any public facing box needs on day one:

• Create a non root user with sudo access and switch to it for daily work.
• Set up SSH key authentication and disable password login entirely.
• Enable UFW with a default deny incoming policy, then allow only SSH, HTTP, and HTTPS.
• Install fail2ban so repeated failed login attempts get banned automatically.
• Turn on unattended upgrades for security patches.

None of this is unique to homelabs, but skipping it is the single most common reason a fresh server gets compromised within days of going public. Starting from a clean, current Ubuntu template on a VPS server makes this step faster, since there is no leftover software or stale configuration to work around.

Step 2: Install Docker and Docker Compose

Docker is the standard way to run self-hosted services in 2026, and for good reason. Each service runs in its own isolated container, dependencies don’t collide with each other, and an entire stack can be described in a single YAML file that you can version, copy, or restore on a new server in minutes.

Installing it takes one command on Ubuntu:

Log out and back in for the group change to apply, then confirm everything works with docker compose version. From here on, every service in this guide gets its own docker-compose.yml file inside a dedicated folder, which keeps configuration organized as the stack grows.

Step 3: Set Up a Reverse Proxy and Point Your Domain

A single VPS has one public IP address, but a homelab usually runs several services. A reverse proxy solves this by routing traffic based on the domain name in the request, so files.yourdomain.com and passwords.yourdomain.com can point to completely different containers on the same server, each with its own automatic HTTPS certificate.

Two tools dominate this space right now. Nginx Proxy Manager gives you a web interface for adding proxy hosts and issuing Let’s Encrypt certificates with a few clicks, which makes it the friendlier starting point. Caddy handles the same job through a short text config file and is popular with people who prefer everything to live in version control.

To get started with Nginx Proxy Manager:

Point an A record for your domain at your server’s IP address, run docker compose up -d, and log in at port 81 to add your first proxy host. One rule matters more than any other here: port 81 is the admin panel, and it should never be reachable from the open internet. Restrict it to your own IP in the firewall, or access it only over the VPN tunnel described in Step 5.

Step 4: Deploy Your First Self-Hosted Services

With the reverse proxy running, it’s time to add services people actually use day to day. A sensible starting stack covers monitoring, passwords, files, and a way to keep track of everything:

• Uptime Kuma watches your services and alerts you the moment one goes down, which matters far more once several apps are running unattended.
• Vaultwarden is a lightweight, self-hosted password manager compatible with the Bitwarden apps and browser extensions.
• Nextcloud or Immich cover file sync and photo backup, replacing paid cloud storage with something you control. Immich in particular has closed most of the feature gap with commercial photo services, including face recognition and a shared album view.
• Homarr or a similar dashboard gives you one page listing every service you run, so you stop hunting for URLs and ports.

Each service gets added to the same Docker network as the reverse proxy, referenced by container name rather than IP address, so nextcloud:80 just works without any manual networking. One service worth calling out by exception: Home Assistant is a poor fit for a VPS, since it relies on discovering devices on your local network. If home automation is part of your plan, keep Home Assistant on hardware at home and use the VPS only for remote access to it.

Step 5: Connect Your VPS Homelab to Your Home Devices

The most capable setups don’t choose between a VPS and home hardware, they combine both. A mesh VPN like Tailscale or WireGuard links your VPS to your home network without opening a single inbound port on your router. Public facing services stay on the VPS, while bulk storage, a NAS, or local devices remain safely at home and are reached only through the encrypted tunnel.

We’ve covered the full Tailscale setup in detail in a separate guide, including how to connect a VPS to home devices without exposing ports. The short version here: once the tunnel is up, your VPS can reach a home file share the same way it reaches a local Docker container, and neither side needs a public listening port for that traffic.

Step 6: Back Up Everything Before You Rely on It

A homelab without backups is a countdown, not a system. The standard approach is the 3-2-1 rule: three copies of your data, on two different types of storage, with one copy kept off site. A backup stored on the same VPS as the data it protects is not a backup. If that server is compromised or the disk fails, both copies disappear together.

Restic is the practical tool of choice here: it encrypts everything, deduplicates so repeated backups don’t balloon in size, and supports S3 compatible storage as a destination. A nightly job pushing your Docker volumes to an off site bucket, with a retention policy like seven daily and four weekly snapshots, covers the vast majority of real world data loss scenarios. The cost is close to nothing. Encrypted, deduplicated, off site backups with a month of retention commonly run under a dollar a month for a typical homelab’s worth of data.

Set up the job, then actually test a restore once. A backup you have never restored is a guess, not a plan.

Pros and Cons of Running a Homelab on a VPS

Advantages:

• Always on, with no dependence on home power or internet reliability.
• A static public IP and clean networking, without router configuration.
• No upfront hardware cost, no electricity bill, and easy vertical scaling when you outgrow your plan.
• A provider handling the physical layer, so a failed drive is not your problem to fix at 3 a.m.

Trade offs:

• Local storage is limited and not a good place for a large media library.
• No native access to local devices like smart home sensors or printers without a VPN bridge.
• A recurring monthly cost instead of a one time hardware purchase.
• You are dependent on your provider’s uptime and support for anything below the operating system layer.

5 Practical Scenarios for a VPS Homelab

Personal cloud replacement. Swap Google Photos, Dropbox, and a paid password manager for Immich, Nextcloud, and Vaultwarden behind a single domain, at a fraction of the combined subscription cost.

Edge node for a hybrid homelab. Keep a large media library and NAS at home, and use the VPS purely as the public facing layer: reverse proxy, DNS, and a VPN hub connecting back to the house.

Personal automation dashboard. Run n8n for workflow automation alongside Uptime Kuma and a Homarr dashboard, replacing several small SaaS tools with one server you fully control.

Shared stack for family or friends. A small group shares one Nextcloud instance, one Vaultwarden vault, and a modestly sized media server, all on a single mid tier VPS.

Learning environment. Practice Docker, Linux administration, and networking on a cheap VPS you can break and rebuild freely, without any risk to your actual home network or files.

Common Mistakes When Building a Homelab on a VPS

Most homelab problems on a VPS trace back to a handful of repeated mistakes:

• Leaving admin panels open to the internet. Nginx Proxy Manager’s port 81 and any database port should be reachable only from your own IP or through the VPN tunnel, never from the public internet.
• Storing backups on the same server they protect. If the VPS goes down or gets compromised, an on box backup goes down with it.
• Trying to host a large media library on VPS storage. Fast NVMe disks on a VPS are usually small and billed per gigabyte; a home NAS is the right place for terabytes of media.
• Underestimating RAM. Several containers running at once add up quickly, and a server that swaps constantly makes every service feel sluggish.
• Skipping monitoring. Without something like Uptime Kuma, a service can silently fail for days before anyone notices.
• Publishing services before basic hardening is done. SSH keys, a firewall, and fail2ban take twenty minutes and prevent the most common automated attacks.

Conclusion

Building a homelab on a VPS comes down to six repeatable steps: secure the base server, install Docker, stand up a reverse proxy, deploy a starter set of services, connect back to your home network if you need one, and back everything up properly from day one. None of it requires specialized hardware or a deep networking background, and the whole stack can realistically be running within an afternoon.

Start small. Pick two or three services that solve a real problem for you today, get backups working before you add a fourth, and expand from there. A VPS server with a clean Ubuntu image is enough to get the first version of your homelab online this week.

FAQ