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

Part of a series on what each size of VPS can do. Earlier: 1 GB and 2 GB. RackNerd sells VPS plans at 1, 2, 4, 6 and 8 GB, and this series follows those sizes.

Four gigabytes is the size where a VPS stops being a place for small tools and becomes a place for real platforms. A code host with built-in CI, a discussion forum, a photo library, a video-call server, a single sign-on system, analytics for your sites, even a modest mail server: these are the programs that quietly refuse to start on 1 GB, and they all fit here. This guide covers fifteen of them, what each one really needs, how to set it up, and where 4 GB runs out.

What is in this guide

• What a 4 GB VPS gives you and your memory budget
• Teams and communities: GitLab, a Discourse forum, a Fediverse server, Nextcloud with online office, Jitsi video calls
• Your own media: an Immich photo library, Jellyfin, a personal web archive
• Platform tools: a mini platform-as-a-service, single sign-on, website analytics, metrics, logs and uptime, a search engine for your site, a small mail server
• Games: bigger Minecraft, Valheim and friends
• What does not fit in 4 GB and when to step up

What a 4 GB VPS gives you

Plans in this class usually have two to four CPU cores, 4 GB of RAM, 60 to 100 GB of disk or more, and a few terabytes of monthly bandwidth. The exact numbers differ plan to plan, so check the listing. At this size the second and third resources start to matter as much as RAM: CPU cores for builds, video calls and game servers, and disk for photos, media and archives. Here are the 4 GB plans with three or more cores, and the ones with the most disk:

Your memory budget

A fresh Debian or Ubuntu server uses 100 to 250 MB idle, which leaves roughly 3.6 GB for your own software. Rough idle figures for the things in this guide (they vary a lot with version, settings and use, so check your own with free -h and docker stats):

Service	Typical memory
GitLab, tuned for a small team	2.5 to 3.5 GB
Discourse (app, database, Redis)	1 to 1.5 GB
GoToSocial / Mastodon (small instance)	150 to 400 MB / 1.5 to 2.5 GB
Nextcloud with database and cache / plus online office	0.6 to 1 GB / plus 1 to 2 GB while editing
Jitsi Meet (idle / with a few people in a call)	1 GB / 1.5 to 2.5 GB
Immich without machine learning	1 to 1.5 GB
Jellyfin (direct play)	300 to 600 MB
ArchiveBox while archiving	0.7 to 1.5 GB
Coolify or similar platform, before your apps	0.7 to 1.2 GB
Authentik / Authelia	1 to 1.5 GB / 30 to 80 MB
Umami / Plausible	200 to 400 MB / 1 to 1.5 GB
Prometheus, Grafana, Loki and Uptime Kuma together	0.8 to 1.5 GB
Meilisearch for a site's worth of content	100 to 500 MB
Small mail server (Stalwart, or Mailu without antivirus)	150 MB to 1 GB
Minecraft (Paper) with 2.5 to 3 GB heap / Valheim	3 to 3.5 GB / 2 to 4 GB

Three realistic combinations:

Setup	What runs	Roughly
Family and friends cloud	Caddy, Nextcloud, Immich (no machine learning), Jellyfin, Vaultwarden	2.5 to 3.2 GB
Community hub	Discourse, Umami, Uptime Kuma, Caddy	2 to 2.8 GB
Dev platform	GitLab on its own, tuned	3 to 3.6 GB

Keep a 2 GB swap file as a safety net (steps are in the 1 GB guide). At this size, swap matters most while installing and upgrading, when GitLab, Discourse and container builds briefly need far more memory than they use afterwards. If you have not yet secured the server and set up SSH keys, do that first, because a server running many public services is a bigger target. Most of the apps below run in containers, so install Docker too, and put a reverse proxy such as Caddy in front of them as described in the 2 GB guide.

1. GitLab for a small team

What it is. A full code platform: Git hosting, merge requests, issue boards, CI/CD pipelines with runners, a container registry and a wiki, all in one install. It is the heaviest program in this guide, and the reason many people buy a 4 GB plan.

Why it suits 4 GB. GitLab's own documentation lists 4 GB as the minimum, and it does run there for a handful of users once you trim it. Idle it uses around 2.5 to 3.5 GB, so it takes most of the server. If you only need Git hosting and light CI, Forgejo or Gitea (see the 1 GB and 2 GB guides) use a tenth of that.

How to set it up. Install the Omnibus package from GitLab's package repository (follow the instructions for your distribution in GitLab's documentation), set external_url to your HTTPS address, and trim it for a small server by adding these lines to /etc/gitlab/gitlab.rb:

puma['worker_processes'] = 0
sidekiq['concurrency'] = 5
prometheus_monitoring['enable'] = false

Then sudo gitlab-ctl reconfigure. These are the kinds of settings GitLab's documentation describes for running in a memory-constrained environment; read that section for your version. Run CI jobs on a separate machine or a separate runner if you can, because a pipeline running on the same server competes with GitLab itself for memory.

Watch out for. Reconfigure and upgrades are the memory spikes, so keep swap on. Do not run Docker builds on the same box as GitLab unless you have limited both. Back up with sudo gitlab-backup create plus a copy of /etc/gitlab, and copy the result off the server. Keep GitLab updated, because it is a large public target.

2. A Discourse forum

What it is. Modern forum software for a community, a product's support section or a hobby group, with categories, trust levels, search and good mobile use.

Why it suits 4 GB. The project says it can run on 1 GB with swap, but it recommends more, and everything feels better with room: the app, PostgreSQL and Redis together use around 1 to 1.5 GB, and the installer rebuilds the container on each upgrade, which is the heavy moment.

How to set it up. Discourse is installed only through its official Docker setup: clone its installation repository into /var/discourse as described in the project's guide, then run:

cd /var/discourse
sudo ./discourse-setup

It asks for your domain, an admin email and mail settings, then builds the container. Later, upgrade from the admin page or with sudo ./launcher rebuild app.

Watch out for. Discourse needs working outgoing email to send sign-up and password messages, so plan on a transactional email service rather than your own server. It also expects the whole server to itself: it manages its own web server inside the container, so run it on its own address or behind a proxy you configure carefully. Back up through the built-in backup tool and copy the files away.

3. A Fediverse server of your own

What it is. A social server that joins Mastodon and the wider Fediverse, for yourself, your family or a community. Mastodon is the well-known one. GoToSocial is a much lighter alternative written in Go, with no PostgreSQL required (it can use SQLite).

Why it suits 4 GB. A small Mastodon instance (web, streaming, background workers, PostgreSQL, Redis) wants a couple of gigabytes and grows with the accounts you follow, so 4 GB is a sensible starting point. GoToSocial for a few people runs in a few hundred megabytes and leaves the rest of the server free.

How to set it up. For GoToSocial: download the release for your platform (or use the container), edit its config.yaml to set host and the paths, run it behind Caddy, and create your account:

./gotosocial --config-path config.yaml admin account create \
  --username you --email [email protected] --password 'a long password'
./gotosocial --config-path config.yaml admin account promote --username you

For Mastodon, follow the project's production guide; it is a longer install and needs outgoing email and, for search, more memory.

Watch out for. A Fediverse server stores media from every account you follow, so disk fills steadily. Set up regular cleanup of remote media. Moving a server's domain later is hard, so choose the name carefully, and back up the database and your config.

4. Nextcloud with online office

What it is. Everything from the 2 GB guide's Nextcloud (files, calendars, contacts, photo sync), plus online editing of documents and spreadsheets in the browser through Collabora Online or OnlyOffice, and room for more users.

Why it suits 4 GB. Nextcloud itself with its database and cache is comfortable for ten or so people. The online editor is the hungry part: the document server adds roughly one to two gigabytes while people are editing. On 2 GB that does not leave enough room, and on 4 GB it does.

How to set it up. The Nextcloud all-in-one container can add an office server for you as an option. If you set it up yourself, run the document server as its own container, give it a memory limit (mem_limit: 1500m in a compose file), and connect it with the matching Nextcloud app. Set PHP's memory_limit to 512 MB, enable OPcache and Redis, and use the system cron for background jobs.

Watch out for. Pick a plan with plenty of disk, because storage is what a cloud outgrows first (see the plans listed above). Video thumbnails and previews are CPU-heavy at first upload. Keep the document server reachable only through your proxy, and back up the files and the database together.

5. Jitsi Meet video calls

What it is. Your own video-conferencing service. Anyone with the link joins from a browser, with no account and no limits on how long a call lasts. It is a good replacement for paid meeting tools for a club, a family or a small team.

Why it suits 4 GB. Jitsi runs several Java processes and a video router, and the project's documentation recommends around 4 GB and a few cores even for small groups. Calls are routed through your server, so the practical limits are CPU and bandwidth, not only memory.

How to set it up. Use the project's apt repository and install the jitsi-meet package; it asks for your hostname and can fetch a free certificate with the script it ships. Open the ports it needs:

sudo ufw allow 80,443/tcp
sudo ufw allow 10000/udp

Point a DNS name at the server before you install. Then turn on authentication so that only people you create can start a meeting; guests can still join through a link. The project's documentation has a section called secure domain for exactly this.

Watch out for. Video eats bandwidth: a meeting of six people can move tens of megabits a second through the server, so check your plan's monthly allowance and expect small meetings, not webinars. Leave it open to everyone and strangers will use it. Try it with your actual group before relying on it.

6. An Immich photo library

What it is. A self-hosted replacement for a cloud photo service: automatic phone backup, albums, sharing, a timeline and maps. It is one of the most popular self-hosted projects of recent years.

Why it suits 4 GB. The project lists 4 GB as its minimum and recommends more, because its optional machine-learning service (face recognition and smart search) is memory-hungry. On a 4 GB VPS the sensible choice is to leave machine learning off. You still get backup, albums, sharing and the timeline, using roughly 1 to 1.5 GB.

How to set it up. Use the compose file and example .env from the project's latest release. Set UPLOAD_LOCATION to a folder with plenty of room and choose a strong DB_PASSWORD. To turn machine learning off, remove the immich-machine-learning service from the compose file (the documentation explains the change for your version), then sudo docker compose up -d and put it behind Caddy.

Watch out for. Photos are large, so this is a plan to pick for its disk (see the list above). The project changes quickly: read the release notes before every upgrade, and keep a backup of both the database and the originals. A server is not a backup, so copy the library somewhere else too.

7. Jellyfin for your own media

What it is. A free media server for the music, films and shows you already own, with apps for phones, TVs and browsers.

Why it suits 4 GB. The server itself uses a few hundred megabytes. What it cannot do on a VPS is convert video on the fly: software transcoding of one 1080p stream can use most of two CPU cores. The answer is direct play, where the file is sent as it is and the device decodes it, which costs almost nothing.

How to set it up.

sudo docker run -d --name jellyfin --restart unless-stopped \
  -p 127.0.0.1:8096:8096 \
  -v /opt/jellyfin/config:/config -v /opt/jellyfin/cache:/cache \
  -v /srv/media:/media:ro jellyfin/jellyfin

Put it behind Caddy, upload your media to /srv/media with rsync, add libraries in the setup wizard, and in each user's settings limit or disable transcoding so that nobody starts a job the server cannot finish.

Watch out for. Only stream media you own, and do not share the server publicly. Streaming uses bandwidth: a film at 8 Mbit/s is about 3.6 GB an hour, so check your plan's allowance. Store files in formats your devices play directly (H.264 in MP4 or MKV is the safest).

8. A personal web archive

What it is. A server that saves copies of the pages you give it: bookmarks, articles, research. ArchiveBox stores each page as HTML, a PDF, a screenshot and more, searchable and independent of whether the original site survives.

Why it suits 4 GB. It drives a real Chromium browser to capture pages, which uses 0.7 to 1.5 GB while it works. On 2 GB this fights with everything else, and on 4 GB it fits next to a few other services.

How to set it up. Run it as the project's container, initialise a data folder, then add pages:

mkdir -p ~/archivebox && cd ~/archivebox
sudo docker run -it -v $PWD:/data archivebox/archivebox init --setup
sudo docker run -it -v $PWD:/data archivebox/archivebox add "https://example.com/page"

Run its web interface behind Caddy with a password. Many people feed it from a browser extension or from an RSS feed on a schedule.

Watch out for. Archives grow fast, since every page keeps several copies, so pick a plan with spare disk and set a limit on what you capture. Keep the web interface private: an archive of pages you saved while logged in can contain things you would not want public.

9. A mini platform-as-a-service

What it is. A self-hosted tool that does what Heroku or Vercel do. You connect a Git repository, and it builds and deploys your app with a web address, HTTPS and a database, from a web dashboard. Coolify and Dokploy are the popular open-source ones, and a single-node k3s cluster (see the 2 GB guide) is the do-it-yourself version.

Why it suits 4 GB. The platform itself takes 0.7 to 1.2 GB before your apps, and builds are memory-hungry spikes. The project's stated minimum is 2 GB, but with 4 GB you can host several small apps and still build them.

How to set it up. Follow the project's own install instructions on a clean server, since these tools set up Docker and the proxy themselves, and read the install script before you run it as root. Then add your server's address, connect your Git provider and deploy an app.

Watch out for. Run it on its own server, not beside other services: it takes control of ports 80 and 443. Builds can exhaust memory, so keep swap on and limit how many run at once. Back up its data and the volumes your apps use.

10. Single sign-on for your own apps

What it is. One login for everything you host. Instead of a separate account in Nextcloud, Immich, Grafana and the wiki, you sign in once, with two-factor authentication, and each app trusts the sign-in. Authentik is a full identity provider with a friendly web interface. Authelia is a tiny alternative that protects apps at the proxy.

Why it suits 4 GB. Authentik runs several processes with PostgreSQL and uses roughly a gigabyte or more, and its documentation asks for at least 2 GB and 2 cores. Authelia needs only tens of megabytes, so it runs almost anywhere.

How to set it up. Authentik's project publishes a compose file; fill in the secret keys it asks for and start it. With Authelia and Caddy, protecting any app takes a short block in the Caddyfile (check the project's documentation for the exact path in your version):

app.example.com {
    forward_auth authelia:9091 {
        uri /api/authz/forward-auth
        copy_headers Remote-User Remote-Groups Remote-Email Remote-Name
    }
    reverse_proxy app:8080
}

Watch out for. A single sign-on server is the key to everything, so use strong passwords and two-factor authentication on the admin account, and back up its database. If it goes down, every app behind it locks you out, so keep a recovery route that does not depend on it.

11. Website analytics that respects visitors

What it is. Your own privacy-friendly analytics for your sites, instead of a large ad company's: page views, referrers, countries, devices, with no cookies and nothing sold. Umami and Plausible Community Edition are the two popular ones.

Why it suits 4 GB. Umami (a Node app and PostgreSQL) is light, about 200 to 400 MB. Plausible stores events in ClickHouse, which needs around two gigabytes by itself, so it belongs on 4 GB. Either one can serve many sites.

How to set it up. Both are provided as Docker compose projects. For Umami, bring up the app and its database, put it behind Caddy, create a website in the dashboard and paste the tracking script it shows into your pages:

<script defer src="https://stats.example.com/script.js" data-website-id="YOUR-SITE-ID"></script>

Watch out for. Keep your own server up to date, because it receives data from every page of every site you track. Back up the database. Check the data-protection rules for your visitors; cookie-free analytics usually need less consent, but you should confirm for your region.

12. Metrics, logs and uptime, together

What it is. A full picture of your servers. Prometheus collects numbers, Grafana draws dashboards and alerts, Loki stores logs so you can search them next to the graphs, and Uptime Kuma checks from the outside that your sites and services respond.

Why it suits 4 GB. The 2 GB guide set up Prometheus and Grafana. Adding Loki and its log collector (an agent such as Grafana Alloy) and Uptime Kuma roughly doubles the footprint, to 0.8 to 1.5 GB in total, which is why this belongs on a bigger plan.

How to set it up. Run them as containers in one compose file, with a memory limit on each. Uptime Kuma, for example:

sudo docker run -d --restart unless-stopped --name uptime-kuma \
  -p 127.0.0.1:3001:3001 -v uptime-kuma:/app/data louislam/uptime-kuma:1

Keep 15 to 30 days of metrics and 7 to 14 days of logs, and set alerts to go to your phone or email.

Watch out for. Logs grow without limit unless you set retention. Keep every port private (a VPN or a firewall rule that allows only your own servers). A monitor is only useful if it runs somewhere other than the servers it watches, so at least run Uptime Kuma from a different provider.

13. A search engine for your site

What it is. Fast, typo-tolerant search for your website or app, instead of paying for a hosted search service. Meilisearch and Typesense are the friendly ones: you send them your content, and your site asks them for results as the visitor types.

Why it suits 4 GB. Search engines like to hold their index in memory, and the memory need grows with how much content you index. A site's worth of articles or a product catalogue is a few hundred megabytes, which is comfortable on 4 GB and awkward on 1 GB.

How to set it up. First make a long random key and keep it (openssl rand -hex 32). Then:

sudo docker run -d --name meili --restart unless-stopped \
  -p 127.0.0.1:7700:7700 -e MEILI_ENV=production \
  -e MEILI_MASTER_KEY=YOUR_LONG_RANDOM_KEY \
  -v /opt/meili:/meili_data getmeili/meilisearch

Put it behind Caddy, create an index, load your documents, and use a search-only key (not the master key) in your website's code.

Watch out for. Never put the master key in a web page. If your data is large, check the project's guidance on memory for your version before choosing. Keep the original data elsewhere, because the search index can be rebuilt but it is not your only copy.

14. A small mail server, with honest caveats

What it is. Email for your own domain, on your own server. At 1 GB and 2 GB this was off the table. At 4 GB a light server is possible: Stalwart is a single, memory-efficient program, and Mailu runs well in containers if you switch off the antivirus.

Why it suits 4 GB. A full-featured stack with spam filtering and antivirus (Mailcow, for example) asks for around 6 GB, mostly for the antivirus scanner. Without that, a small mailbox set fits in well under 4 GB.

How to set it up. Follow the chosen project's installation guide. Whichever you pick, the DNS records matter more than the software: MX, an SPF record such as v=spf1 ip4:YOUR_SERVER_IP -all, DKIM keys, a DMARC policy such as v=DMARC1; p=none; rua=mailto:[email protected], and a reverse DNS (PTR) entry matching your mail host name, which you may need to ask your provider to set.

Watch out for. This is the one idea here that can be a lot of ongoing work. Check that your provider allows outgoing mail on port 25 (many block it by default), and test a new address on a blocklist checker before you depend on it, because a fresh address can already be listed. Delivery to the big mail providers is the hard part. Many people self-host receiving and use a transactional email service for sending. Keep backups of the mailboxes and the DKIM keys.

15. Bigger Minecraft, Valheim and friends

Minecraft. With 4 GB you can run a Paper server for a group of friends with a handful of plugins, and give it a bigger fixed heap than on 2 GB:

java -Xms2G -Xmx3G -jar paper.jar --nogui

That leaves about a gigabyte for the system. Expect comfortable play for five to fifteen players with a modest view distance (6 to 8), and a small modpack is possible. Run it in tmux or as a systemd service, and open 25565/tcp. Large modpacks and big player counts still want 8 GB or more.

Valheim. The dedicated server uses roughly 2 to 4 GB depending on the world, so it just fits. Install it with SteamCMD (application 896660), start it with the world name and a password of at least five characters that does not contain the world name, and open UDP ports 2456 to 2458.

Lighter games. Terraria, Factorio and many older and indie dedicated servers use far less and can share the server with other things. Check each game's own server requirements.

Watch out for. Game servers care about CPU speed and about distance to the players, so choose the nearest location (see the list above) and a plan with enough cores. Anything that needs 8 GB or more, such as ARK, Rust, Palworld or Satisfactory, belongs on a bigger plan. More in VPS plans for game servers.

What does not fit in 4 GB

• GitLab with a busy team, with CI runners on the same server, a container registry and many projects. It runs in 4 GB for a handful of people, and gets slow beyond that.
• Immich with machine learning, Mailcow with antivirus, or Jitsi with many participants. Each wants 6 GB to 8 GB or more.
• Large Java or Elasticsearch back ends with big indexes.
• Video transcoding for several people at once. A CPU with many fast cores or a graphics card does this; a typical VPS does not.
• Several heavy platforms together. GitLab plus a forum plus a photo library will use all the memory. Pick one big app per 4 GB.
• Large game servers: ARK, Rust, Palworld, Satisfactory and heavily modded Minecraft.

Planning something large? See self-hosted apps and what they need.

When to step up

Move to a bigger plan when swap is in constant use, when the kernel kills programs for lack of memory (dmesg | grep -i oom will show it), or when builds, calls and games are slow because every core is busy. The next step, 6 GB to 8 GB, is where GitLab with real CI, Immich with face recognition, Mailcow, Jitsi with bigger meetings and most large 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.