What can you do with a VPS? 20 real uses

What can you do with a VPS?

A VPS (virtual private server) is a Linux machine with a public IP address that runs whether or not your laptop is on, so anything that has to stay reachable can live there. In practice that means websites, a private VPN, your own file and photo storage, media, game servers, scheduled scripts, and a growing pile of AI tooling. Below are twenty things people genuinely run, ordered roughly by how often they are the reason someone rents a server in the first place.

Each entry says what the job is, what it costs you in memory, and where the full guide lives. If you want the wider catalogue of applications rather than the jobs, the companion list of apps worth self-hosting in 2026 goes app by app.

The 20 things people actually run

1. Host a website or a web app. This is still the most common answer. A single small server runs nginx or Apache, PHP, and a database happily on 1 GB of RAM, and the classic starting point is a LAMP stack on Ubuntu 24.04. Add a free certificate with Certbot and Let's Encrypt on nginx, because a bare IP address on port 80 makes browsers show a warning that costs you every visitor.

1. Run several sites and apps on one box. One server can serve a dozen names if something in front sorts the requests by hostname. A reverse proxy does that job and renews the certificates too, which is why Traefik in front of multiple Docker apps is the usual second step. The saving is real: five projects on one 4 GB server cost less than five small servers, and they are easier to back up.

1. Your own VPN. A VPS gives you an exit IP you control, so public Wi-Fi cannot read your traffic and your home services stay off the open internet. WireGuard uses under 50 MB of memory and runs in the kernel, so the server barely notices it, and the self-hosted WireGuard VPN guide covers the handshake and DNS problems that catch people. The two products are often confused, so the VPS versus VPN comparison is worth a minute first.

1. A password manager you own. Vaultwarden speaks the Bitwarden protocol, so every official app and browser extension connects to your server instead of a company's. It needs about 150 MB of RAM and almost no disk, which makes Vaultwarden on a VPS the best first project on this list. This box holds every password you have, so treat its certificate and its backups as part of the install, not as a later chore.

1. Cloud file storage and calendars. Nextcloud replaces a paid Drive or Dropbox plan with sync clients for every desktop and phone, plus calendar and contacts. Budget 1 to 2 GB of RAM plus the size of your files, and install it on PostgreSQL from the start: the Nextcloud with Docker, TLS and backups guide explains why migrating the database later is the most common way people wreck an instance.

1. A photo library with phone upload. Immich auto-uploads your camera roll and does face and object search, which is the feature that finally gets people off Google Photos. It is the hungriest application here because of the machine-learning container, so read the self-hosted Immich guide before you buy the smallest plan. Immich's requirements page asks for at least 6 GB of RAM (8 GB recommended) and 2 CPU cores, or 4 GB of RAM with the machine-learning features turned off. If that memory floor is more than your plan can spare, PhotoPrism and Immich compared side by side weighs the two on RAM, phone apps and backup commands so you can pick the one your server will actually hold. Pin a version rather than pulling latest, since breaking changes still land between releases.

1. A media server for your own library. Jellyfin streams your films and shows to a TV app, a browser, or a phone with no account and no paywall on remote playback. It idles around 1 to 2 GB of RAM, though Jellyfin's own hardware guide recommends 8 GB for an average deployment and says 4 GB may be enough on a Linux server without a desktop. The thing that decides whether it works is transcoding: Jellyfin on a VPS shows how to keep files in a format clients play directly, so the server only moves bytes. Once it is running, Halcyon reskins the same library as a 1990s rental store you browse shelf by shelf, which turns out to be a far better way to pick something than scrolling an endless grid of thumbnails.

1. A game server for friends. A Minecraft server for a handful of players wants 2 to 4 GB of RAM and a machine that stays up when the host player goes to bed, which is exactly what a VPS is. The Minecraft server on a VPS guide covers the Java memory flags and running it under systemd so a crash restarts itself.

1. Scheduled scripts, scrapers, and bots. Anything that has to run at 3 in the morning needs a machine that is awake at 3 in the morning. Write the job as a systemd service with a timer rather than a cron line, because you get logs, failure status, and a clean way to test it: systemd services and timers on a VPS has the unit files. A Discord or Telegram bot is the same pattern with a long-running process instead of a timed one.

1. Automation workflows. n8n gives you a visual builder for the work Zapier charges per task for, and running it yourself removes the per-task bill. Data size still has a ceiling, but it is yours to set: n8n caps payloads at 16 MiB by default through N8N_PAYLOAD_SIZE_MAX, and you can raise it and restart. It sits around 500 MB of RAM. Set the encryption key explicitly, as self-hosted n8n with HTTPS shows. Otherwise n8n generates a key on first launch and saves it in its ~/.n8n folder, and if that folder is not on a persistent volume, a container rebuild loses the key and makes every saved credential unreadable.

1. Run a language model yourself. Ollama serves open-weight models over a local API, so prompts and documents never leave your server. On a CPU-only VPS expect a few words per second rather than instant answers, and budget about 8 GB of RAM for a typical 8B model (Ollama's default llama3.1:8b download alone is 4.9 GB, before the context is counted): running Ollama to self-host an LLM has honest numbers. For a workflow platform on top of the model, Dify on a VPS adds a UI and retrieval.

1. Give a coding agent somewhere to live. An AI coding agent that works for an hour is useless if it dies when you shut your laptop, so people put it on a server inside a terminal multiplexer and reconnect later. Claude Code on a VPS with tmux is the setup, and running a coding agent on a VPS covers the general shape. Give it its own unprivileged user and a directory it cannot escape.

1. Host MCP servers for your assistants. MCP (model context protocol) servers are small always-on processes that expose tools and data to an AI client, and always-on is the part a laptop cannot do. MCP servers on a VPS walks through running them behind TLS with authentication, which matters because an open MCP endpoint is a tool anybody can call.

1. Watch your other servers. Uptime Kuma pings your sites and alerts you on almost any channel, and it runs in about 200 MB. The rule people miss: monitor production from a different machine, because Uptime Kuma status monitoring running on the box it watches cannot tell you when that box dies.

1. Real metrics, not just up or down. When you have a fleet rather than one server, you want CPU, disk, and service metrics with history and triggers. A Zabbix monitoring server does that with an agent on each host, and Zabbix's own hardware examples list 2 CPU cores and 8 GiB of memory even for the smallest installation (1,000 monitored metrics), plus its own database. Start with the simple uptime check and graduate when you have something to graduate to.

1. Offsite backups for everything else. A backup on the same disk as the data is not a backup. A cheap VPS with a large volume makes a fine destination, and restic backups on a VPS gives you encrypted, deduplicated, versioned snapshots with a restore you can actually test. Test it monthly, because an untested backup is a hope.

1. Your own CI runner. Hosted build minutes run out, and a self-hosted runner keeps your caches warm and your secrets local. A self-hosted GitHub Actions runner shows the install and the isolation, which matters most on public repositories where a pull request can run code on your machine.

1. Team chat you control. Rocket.Chat covers threads, calls, and integrations for a team that would rather not pay per seat. It is one of the heavier entries on this list: as of 2026-10-12, Rocket.Chat's own system requirements give even the smallest tier (up to 500 concurrent users, no high availability) a minimum of 4 GiB of memory for the Rocket.Chat node and another 4 GiB for MongoDB, listed with three replica members, so a server holding the app and one MongoDB member needs at least 8 GB, and Rocket.Chat 8.x needs MongoDB 8.0 or later. Rocket.Chat with Docker Compose walks the version ladder, since skipping a MongoDB major version during an upgrade strands the database.

1. A private network across all your machines. Once you have several servers and a laptop, a mesh network is easier to live with than a single hub, and Headscale as a self-hosted Tailscale control server keeps the coordination on your own box. When a whole network needs to be reachable rather than one host, such as a home LAN or a provider's private range, a VPS advertising those routes as a subnet router saves you installing the client on every device behind it. Pair it with the habit of treating hosts as a group, which is what managing multiple Linux servers is about.

1. A lab, and a mail server if you insist. A VPS is a safe place to break things: try a FreeBSD 15 server, or run virtual machines inside your server where the plan allows nested virtualization. Email sits at the bottom on purpose, because most providers block outbound port 25 and deliverability is a long fight, so read self-hosted email with Mailcow with your eyes open.

How much server does each of these need?

Memory is usually the first limit you hit, though CPU and disk still count: Immich, for one, asks for at least 2 CPU cores on top of its RAM. A 1 GB plan runs one small thing: a website, a VPN, a password manager, a bot. A 4 GB plan is the comfortable place to run a handful of services behind one proxy, which is what most people on this page end up doing.

The awkward size is 2 GB. That is where somebody adds a third container, the kernel kills it silently, and nothing in the application log explains why. Run sudo dmesg | grep -i "out of memory" and you will see the Out of memory: Killed process line that the container runtime swallowed. AI workloads break the rule: a typical 8B language model as Ollama ships it wants roughly 8 GB of RAM to run comfortably, and photo machine learning is similar. Quantization changes that figure a lot, since PrismML's 1-bit Bonsai 8B packs its 8B parameters into a 1.16 GB file that runs on llama.cpp. Rocket.Chat is the other exception, with a documented minimum of 4 GiB each for the chat server and its database, so at least 8 GB.

Disk follows your data. Photos, media, and backups are the only entries here that need hundreds of gigabytes. Media also needs scratch space on top of the library: Jellyfin's hardware guide recommends 100 GB of SSD for the OS, Jellyfin's files and the transcoding cache, and sizes that cache as your largest file times your peak number of concurrent streams. Everything else is measured in tens of gigabytes rather than hundreds, so check the disk on the plan you pick against the data you expect to keep.

Before you run any of it

Every use above assumes the same base: a machine you can reach, a user that is not root, and a firewall.

sudo apt update && sudo apt upgrade -y
sudo adduser deploy
sudo usermod -aG sudo deploy
sudo ufw allow OpenSSH
sudo ufw enable
sudo ufw status

sudo ufw status should print Status: active with a line allowing 22/tcp. Open a second terminal and confirm you can still log in before you close the first one, because a firewall that locks you out needs a console rescue from your provider's panel. The first ten minutes on a new VPS covers this end to end, and SSH hardening turns off password login so the constant background brute-force attempts stop mattering.

Almost every application above ships as a container, so install Docker once and the rest of the list becomes copy and paste:

curl -fsSL https://get.docker.com | sudo sh
sudo usermod -aG docker "$USER"
newgrp docker
docker run --rm hello-world

A failure reading permission denied while trying to connect to the Docker daemon socket means the group change has not reached your shell yet, so log out and back in. Docker Compose basics explains the file format that the guides above all use.

What a VPS is not good for

Some honest limits. Heavy graphics work and model training need a GPU, and a standard VPS does not have one, so inference on CPU stays slow no matter how much RAM you add. When a GPU or a few terabytes of disk is the thing you actually need, a machine at home is the honest alternative, and Proxmox at home versus renting a VPS does the hardware and electricity math against a monthly bill. Anything where five minutes of downtime causes real harm, such as a home alarm or a medical alert, does not belong on a hobby server you upgrade on Sunday nights. A single server is also a single point of failure, so a service that must never be down needs a second box and a tested way to switch to it.

Email deserves its own warning even though it is on the list. Outbound port 25 is blocked by most providers, and even with it open, a new IP address with no reputation lands in spam until the DNS records are right and the address has been warmed up. It is a real ongoing job rather than a weekend.

FAQ

What is the most common use for a VPS?

Hosting a website or web application. A small server running nginx or Apache with PHP and a database handles a personal site, a client site, or a small product on 1 GB of RAM, and it is the cheapest way to get a real public IP address with full control of the stack. The second most common answer is a private VPN, because a server you own gives you an exit address nobody else shares.

How much RAM do I need for the things on this list?

For one small service, 1 GB works. For a handful of services behind one reverse proxy, 4 GB is the comfortable size, and it is the plan most people settle on. AI workloads are the exception: a typical 8B language model in Ollama wants roughly 8 GB to run comfortably, though heavily quantized builds need far less, and photo machine learning wants a similar amount. Rocket.Chat also sits in that bracket, since its documented minimum is 4 GiB each for the app and MongoDB. Disk only matters if you are storing media, photos, or backups.

Can I run more than one of these on the same server?

Yes, and that is normal. Put each application in its own container, publish nothing directly to the internet, and let one reverse proxy handle the names and the certificates. The limit is memory rather than the number of applications, so add up the honest figures above, then leave headroom of at least 25 percent so an upgrade or a backup run does not trigger an out-of-memory kill.

Do I need to know Linux to use a VPS?

You need the basics: connecting over SSH, editing a file, and reading a log. Everything else in these guides is copy, paste, and check the output against what the guide says you should see. If you would rather click than type, a control panel manages the applications for you, and the Cloudron, CasaOS and Coolify comparison covers what each one costs you in flexibility.

Is a VPS cheaper than paying for these services?

Usually, once you run more than one. A single 4 GB server can replace a file sync subscription, a password manager plan, a photo storage plan, and an automation tool bill at the same time. The cost you take on instead is your own time: updates, certificates, and backups are now your job, so the saving is real only if you actually do them.