What can you do with a 2 GB VPS? 15 useful and fun things to run

Part of a series on what each size of VPS can do. Previous: what can you do with a 1 GB VPS.

Two gigabytes is where a VPS stops feeling like a squeeze. Everything in the 1 GB guide still fits, with room to spare, and a new class of software becomes comfortable: Docker with several containers running at once, a proper WordPress stack with caching, a real database server, Java programs, a Minecraft server for a few friends, and a remote development machine. This guide covers fifteen things that make good use of 2 GB, what each one really needs, how to set it up, and where the limits are.

What is in this guide

• What a 2 GB VPS gives you and three sample setups
• Running apps: a Docker and reverse proxy stack, WordPress done properly, Nextcloud for a few people, a wiki and knowledge base, a pile of small apps, a private chat server, music and audiobook streaming
• Building and testing: a build server, a database server, hosting your own apps, a remote development machine, a Kubernetes lab, headless browser automation
• Monitoring: Prometheus and Grafana
• Games: Minecraft and other game servers
• What does not fit in 2 GB and when to step up

What a 2 GB VPS gives you

Plans in this class usually come with one or two CPU cores, 2 GB of RAM, 30 to 60 GB of disk and a bandwidth allowance of a few terabytes a month. Check the exact figures in the listing above, because plans differ. The number of CPU cores matters more at this size than it did at 1 GB, because builds, game servers and browsers are CPU-hungry. Here are the 2 GB plans with at least two cores:

Your memory budget, and three sample setups

A fresh Debian or Ubuntu server uses 100 to 250 MB idle. That leaves around 1.7 GB for your own software. Rough idle figures for what is in this guide (yours will differ; check with free -h and docker stats):

Service	Typical memory
Docker plus a reverse proxy (Caddy, nginx)	100 to 200 MB
WordPress stack (nginx, PHP-FPM, MariaDB)	300 to 600 MB
Nextcloud with database and Redis	400 to 800 MB
BookStack or Wiki.js with its database	250 to 500 MB
Navidrome (music) / Audiobookshelf	30 to 80 MB / 100 to 250 MB
Prosody (XMPP chat) / Matrix Synapse	20 to 60 MB / 400 to 800 MB
PostgreSQL or MariaDB for side projects	100 to 300 MB
Prometheus plus Grafana	300 to 600 MB
code-server (VS Code in a browser)	300 to 700 MB
One headless Chromium	300 to 500 MB while it runs
k3s (single-node Kubernetes), before your apps	500 MB to 1 GB
Minecraft server (Paper), Java heap	1 to 1.5 GB

That table shows how the memory gets used. Three realistic setups:

Setup	What runs	Roughly
Family cloud	Caddy, Nextcloud with Redis, Vaultwarden, Navidrome	1 to 1.3 GB
Dev lab	code-server, PostgreSQL, your app, a CI runner	1.2 to 1.6 GB
Game night	A Minecraft server on its own	1.6 to 1.9 GB

Add a swap file as a safety net (steps are in the 1 GB guide: a 1 to 2 GB swap file is sensible at this size too). Swap is for brief spikes, not for running out of memory every day. New to servers? Do the basics first: secure the server and set up SSH keys.

1. A Docker stack with a reverse proxy

What it is. Docker lets you run each app in its own container, and a reverse proxy sits in front, giving every app a clean web address with automatic HTTPS. It is the most popular way to run several self-hosted apps on one server, and 2 GB is the point where it becomes comfortable. (First, install Docker.)

Why it suits 2 GB. Docker itself uses 50 to 100 MB, and Caddy adds a few tens of megabytes. Each app then adds its own share, so you can run four or five small ones together.

How to set it up. Create a folder for the stack and put this in compose.yaml. The example runs Caddy and Vaultwarden together; add more apps as more services in the same file:

services:
  caddy:
    image: caddy:2
    restart: unless-stopped
    ports: ["80:80", "443:443"]
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - caddy_data:/data
  vaultwarden:
    image: vaultwarden/server:latest
    restart: unless-stopped
    volumes:
      - ./vw-data:/data
volumes:
  caddy_data:

And a Caddyfile next to it. Caddy gets and renews free HTTPS certificates by itself, as long as the domain name points at your server:

vault.example.com {
    reverse_proxy vaultwarden:80
}

Then sudo docker compose up -d. Adding another app is two steps: a new service in the file, and a new block in the Caddyfile.

Watch out for. Put a memory limit on each container (add mem_limit: 400m under a service) so one misbehaving app cannot take the whole server down. Do not publish database ports to the internet. Keep containers updated with docker compose pull, and back up the volumes.

2. WordPress, done properly

What it is. On 1 GB, WordPress works but you have to squeeze it. On 2 GB you can run a proper stack and even host a few small sites.

Why it suits 2 GB. A tuned stack of nginx, PHP-FPM and MariaDB sits around 300 to 600 MB. That leaves room for a caching layer and for traffic spikes.

How to set it up. Follow how to install WordPress on a VPS, then tune it:

• PHP-FPM: set pm = ondemand and pm.max_children = 6. A WordPress request uses 50 to 100 MB, so the limit stops a traffic burst from using all the memory.
• MariaDB: set innodb_buffer_pool_size = 256M.
• Object cache: sudo apt install redis-server, set maxmemory 64mb in /etc/redis/redis.conf, and add a Redis object cache plugin to WordPress.
• Page cache: use a page-caching plugin or nginx's FastCGI cache so most visitors are served a stored copy without touching PHP at all. This does more for speed than any other step.
• HTTPS: a free certificate through Certbot.

Watch out for. Plugins are the real memory hogs, so keep the list short. Keep WordPress, themes and plugins updated, because that is how most sites get hacked. See web servers on a VPS for the nginx side. A busy shop (WooCommerce) needs more; see the limits.

3. Nextcloud for you and a few others

What it is. Your own cloud: file sync, photo backup from your phone, calendars, contacts and shared folders, replacing a paid cloud storage subscription.

Why it suits 2 GB. A Nextcloud with its database and a Redis cache takes roughly 400 to 800 MB, which is comfortable for one to three people. On 1 GB it is a struggle.

How to set it up. The all-in-one container image is the simplest route, and it sets up the database, cache and HTTPS for you. Choose a plan with plenty of disk, because storage is what you outgrow first:

Watch out for. Photo previews and video thumbnails use a lot of CPU and memory the first time, so let them generate slowly, or turn previews off for big libraries. Set PHP's memory_limit to 512 MB, enable OPcache, and use the system cron for background jobs rather than the default AJAX mode. Back up both the files and the database.

4. A wiki and knowledge base

What it is. A place for notes, documentation, runbooks, recipes or a team handbook, with search and a tidy structure. BookStack (PHP and MariaDB) is simple and friendly, and Wiki.js (Node and PostgreSQL) is another popular choice.

Why it suits 2 GB. Each one needs an app plus a database, which is 250 to 500 MB together, and that is too much to squeeze in beside other things on a 1 GB plan.

How to set it up. Both are easiest as Docker containers in the stack from idea 1, behind Caddy with HTTPS. Give each its own database container, or share one PostgreSQL or MariaDB between several apps to save memory.

Watch out for. Wikis are only useful if you can recover them, so back up the database and any uploaded files. Switch on user accounts and turn off public sign-up unless you want strangers writing in it.

5. A pile of small apps

This is where 2 GB really pays off: not one big app, but many small ones sharing the server. Each of these uses tens of megabytes to about 100 MB:

• ntfy is a tiny push-notification server. Any script can send a message to your phone with a single command, such as curl -d "Backup finished" https://ntfy.example.com/mytopic. It pairs well with the bots and jobs from the 1 GB guide.
• Healthchecks is a dead-man's switch for scheduled jobs. Your backup script pings it when it finishes, and if the ping does not arrive on time, you get an alert. It catches the jobs that fail silently.
• Linkding is a fast bookmark manager with tags and full-text search, and a browser extension.
• A start page such as Homepage gives you one dashboard with links and status for everything you run.
• A notes or memo app such as Memos is a quick, private place to jot things down.

How to set it up. Each has a container image and a short compose example in its documentation. Add them as services in the same compose.yaml and give each a hostname in the Caddyfile.

Watch out for. It is easy to keep adding. Check docker stats now and then, give each container a memory limit, and remove what you stop using.

6. A private chat server

What it is. Your own messaging service for family or friends, without a company reading it. There are two main options. XMPP (with Prosody) is old, simple and extremely light. Matrix is more modern and has richer rooms and clients.

Why it suits 2 GB. Prosody uses 20 to 60 MB and runs happily on 1 GB. Matrix's reference server, Synapse, with PostgreSQL, uses roughly 400 to 800 MB even for a few users, which is why it belongs on 2 GB. Lighter Matrix servers written in Rust also exist.

How to set it up. For XMPP: sudo apt install prosody, set your domain in /etc/prosody/prosody.cfg.lua, get a certificate, and create users with sudo prosodyctl adduser [email protected]. Phone and desktop apps connect to it like any chat service. For Matrix, use the Docker image of your chosen server and put it behind Caddy.

Watch out for. A chat server needs a domain name and correct DNS records. If you take part in public Matrix rooms, the server's database grows quickly, so keep it to private use, or set a retention policy.

7. Your own music and audiobook streaming

What it is. A streaming service for the music and audiobooks you already own. Navidrome serves your music library to phone and desktop apps (it speaks the common Subsonic protocol). Audiobookshelf does the same for audiobooks and podcasts, and remembers where you stopped on every device.

Why it suits 2 GB. Navidrome is one small Go program, about 30 to 80 MB. Audiobookshelf uses 100 to 250 MB. The real limit is disk, because a music library of tens of gigabytes needs a plan with plenty of storage (see the list in idea 3).

How to set it up. Both run as containers. For Navidrome:

sudo docker run -d --name navidrome --restart unless-stopped \
  -p 127.0.0.1:4533:4533 -v /opt/navidrome:/data \
  -v /srv/music:/music:ro deluan/navidrome

Put it behind Caddy, upload your music to /srv/music with rsync, and connect a Subsonic-compatible app.

Watch out for. Only stream music you own, and do not share the server publicly. Streaming uses bandwidth: music at 128 kbit/s is about 58 MB an hour. Video is a different matter. Transcoding video needs far more CPU than a one or two core VPS has, so a video library should be played directly rather than converted.

8. A build and test server

What it is. A machine that builds and tests your code every time you push, so you are not waiting on your laptop. Pair a self-hosted Git server (see the 1 GB guide) with a CI runner. Woodpecker and Drone are small CI systems, and Forgejo has its own runner.

Why it suits 2 GB. The CI system itself is light, around 50 MB idle. The builds are what take memory, and they come in bursts. Compiling a mid-sized project or running a test suite with a database can use a gigabyte or more for a minute.

How to set it up. Run the CI server and one runner as containers and connect the runner to your Git server. Limit the runner to one job at a time, so two builds cannot run together and exhaust the memory.

Watch out for. One CPU core makes builds slow, so for this job prefer the 2 GB plans with two cores. Docker images and build caches fill the disk, so run docker system prune now and then.

9. A real database server for your projects

What it is. A PostgreSQL or MariaDB server that all your side projects share, instead of each carrying its own. It is useful for learning, for hobby apps and for data you want to keep in one place.

Why it suits 2 GB. A database likes memory for caching data. With 2 GB you can give it a few hundred megabytes and still run your apps next to it.

How to set it up. sudo apt install postgresql. In /etc/postgresql/*/main/postgresql.conf, set shared_buffers = 256MB and leave listen_addresses as localhost. Create a database and a user for each project:

sudo -u postgres createuser --pwprompt myapp
sudo -u postgres createdb -O myapp myapp

Reach it from your own computer through an SSH tunnel (ssh -L 5432:127.0.0.1:5432 user@your_server_ip) or over your VPN, never over the open internet.

Watch out for. A database exposed to the internet will be attacked within hours, so keep it private. Back up with pg_dump every night and copy the dumps elsewhere. Redis is a good companion for caching if your apps use it; give it a maxmemory limit.

10. Hosting your own apps

What it is. Running the web apps you write or maintain: a Flask or Django site, a Node.js app, a Go service, a Ruby on Rails app. A server of your own is the cheapest way to host side projects, and a good way to learn how deployment works.

Why it suits 2 GB. A Django app with two Gunicorn workers uses roughly 150 to 300 MB, a Node app 100 to 200 MB, and a Go binary often under 50 MB, so you can run several next to a database. On 1 GB, one app and its database already use most of the room.

How to set it up. Run each app as a systemd service with its own user, behind nginx or Caddy. The web servers page has the Gunicorn setup. Systemd can also cap an app's memory, so one runaway app cannot take the others down. Add this under [Service] in the unit file:

MemoryMax=400M
Restart=on-failure

Watch out for. Keep secrets out of your code, and keep a copy of the deploy steps (a short script is enough) so you can rebuild the server in minutes.

11. A remote development machine

What it is. Your editor and tools running on the server, so you can work from any computer, a tablet or a Chromebook with the same setup, and your builds use the server's connection. Two ways to do it: use VS Code's Remote-SSH feature, which runs a helper on the server, or run code-server, which serves VS Code in your browser.

Why it suits 2 GB. Either one uses 300 to 700 MB depending on extensions and the size of the project, and then you still need memory for what you are building.

How to set it up. With Remote-SSH, nothing to install on the server but SSH: add the host to your editor and connect. With code-server, install it, set a password in its config, keep it listening on 127.0.0.1:8080, and open it through an SSH tunnel: ssh -L 8080:127.0.0.1:8080 user@your_server_ip.

Watch out for. Never expose code-server to the internet without HTTPS and a strong password, because it gives full shell access. Pick a location near you, because typing latency matters in an editor:

12. A Kubernetes lab

What it is. A single-node Kubernetes cluster for learning. K3s is a trimmed-down Kubernetes that installs with one command and runs real Kubernetes workloads, including the tools you will meet at work.

Why it suits 2 GB. A k3s server uses roughly 500 MB to 1 GB for itself before you run anything, so it fits on 2 GB with room for a few small apps. That is enough to learn deployments, services, ingress and volumes.

How to set it up. Use the one-line installer from the k3s project, then sudo k3s kubectl get nodes to check it works. Deploy a small app with a manifest and expose it through the built-in ingress.

Watch out for. This is for learning, not for production. If memory is tight, use swap, and keep the workloads tiny. When you break it, reinstall: that is part of the lesson.

13. Headless browser automation

What it is. A real web browser with no window, controlled by a script. Use it to take screenshots of pages on a schedule, create PDFs, test your own site, check for broken links, or fetch pages that need JavaScript to show anything.

Why it suits 2 GB. One Chromium instance uses 300 to 500 MB while it runs, which is more than a 1 GB server can spare. With 2 GB you can run one at a time comfortably.

How to set it up. With Python and Playwright: pip install playwright, then playwright install --with-deps chromium, and a script like this:

from playwright.sync_api import sync_playwright

with sync_playwright() as p:
    browser = p.chromium.launch()
    page = browser.new_page()
    page.goto("https://example.com")
    page.screenshot(path="shot.png")
    browser.close()

Run it from cron. Start the browser, do the job and close it every time, so the memory is freed between runs.

Watch out for. Run one browser at a time. Respect the terms and robots rules of the sites you visit, and do not hammer them. Only automate sites you own or are allowed to.

14. Prometheus and Grafana monitoring

What it is. A monitoring stack. Prometheus collects numbers (CPU, memory, disk, request rates) from your servers and apps, and Grafana draws graphs and dashboards and sends alerts. It is far more detailed than a simple up or down check.

Why it suits 2 GB. Prometheus plus Grafana uses roughly 300 to 600 MB, depending on how many things you watch and how long you keep the data.

How to set it up. Install prometheus and prometheus-node-exporter from your distribution, run Grafana as a container, and add Prometheus as its data source. Install the node exporter on each server you want to watch and add them as scrape targets. Scraping every 30 to 60 seconds, and keeping 15 to 30 days of data (--storage.tsdb.retention.time=30d), keeps memory and disk use down.

Watch out for. Keep the Prometheus and node exporter ports private, using a VPN or a firewall that only allows your own servers. Like any monitor, it is most useful when it runs on a different server from the ones it watches.

15. Minecraft and other game servers

What it is. A server for you and your friends that runs when your own computer is off.

Minecraft. A Java server for a few friends is realistic on 2 GB. Use Paper, a faster Minecraft server, install the Java version your Minecraft version needs (sudo apt install openjdk-21-jre-headless where it is available), and give it a fixed heap that leaves room for the system:

sudo adduser --system --group --home /opt/minecraft minecraft
# put paper.jar in /opt/minecraft, then as that user:
java -Xms1G -Xmx1280M -jar paper.jar --nogui

The first run stops and asks you to accept the Minecraft EULA by setting eula=true in eula.txt. In server.properties, lower view-distance to about 6 and simulation-distance to about 4, which cuts memory and CPU a lot. Open the port with sudo ufw allow 25565/tcp, and run the server in tmux or a systemd service so it survives you logging out. Expect smooth play for two to five players. Mods and big worlds need more RAM.

Other games. Terraria and Factorio servers for a group of friends fit easily, and so do many older and indie games with light dedicated servers. Check each game's own server requirements. Big survival games (Valheim, ARK, Rust and the like) want 4 GB to 8 GB or more.

Watch out for. A game server is as fast as its location is close, and CPU speed matters more than the number of cores. Pick the 2 GB plan with two cores and a location near your players. More on this in VPS plans for game servers.

What does not fit in 2 GB

• GitLab still wants 4 GB or more. Forgejo or Gitea is the right choice here.
• Jitsi Meet and video calls with more than two or three people need more CPU, RAM and bandwidth.
• A full mail server with spam filtering and antivirus, for the same reasons as on 1 GB. Mail also needs good sender reputation and a provider that allows outgoing mail on port 25.
• Busy WooCommerce or Magento shops and Nextcloud with many users.
• Elasticsearch, big Java back ends and heavily modded Minecraft.
• Video transcoding (Plex or Jellyfin converting formats on the fly). Direct play is fine, but converting video needs a lot of CPU.
• Large game servers such as Valheim, ARK and Rust.

Planning a heavy self-hosting setup? See self-hosted apps and what they need.

When to step up

Move to a bigger plan when swap is in constant use, when apps are being killed for lack of memory (dmesg | grep -i oom shows it), or when builds and game servers lag because the single core is saturated. The jump to 4 GB doubles your room again, and it is where GitLab, multi-user Nextcloud and bigger game servers become comfortable. Moving is simple: set up the new server, restore your configuration and data, and switch your domain over.

Looking for the lowest price at any size? See the cheapest VPS plans right now, or check the sales calendar for the best deals of the year.