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

Part of a series on what each size of VPS can do. Earlier: 1 GB, 2 GB and 4 GB.

Six gigabytes is the size where you stop choosing one big program and start running a small data centre. The 4 GB guide ended with a list of things that nearly fit: Immich with face recognition, a complete mail server with antivirus, GitLab with real CI, bigger game servers. They fit here. It is also the first size where a few genuinely new ideas open up, such as running small AI models on your own hardware, a cloud desktop, or a multi-node Kubernetes lab. This guide covers fifteen uses, what each one really needs, how to set it up, and what still does not fit.

What is in this guide

• What a 6 GB VPS gives you and your memory budget
• Platforms for teams: GitLab with CI and a registry, a complete mail server, a Mastodon community with search, a small web host for clients
• Your data: Immich with face recognition, a paperless office, a production database server, a search and log platform, automation and dashboards
• Building and experimenting: a build server, a multi-node Kubernetes lab, small AI models, a cloud desktop
• Everything at once and games: an everything box, modded Minecraft and bigger game servers
• What does not fit in 6 GB and when to step up

What a 6 GB VPS gives you

Plans in this class usually have three or four CPU cores, 6 GB of RAM, 100 GB or more of disk and several terabytes of bandwidth. Check the listing, because they differ. At this size CPU becomes as important as memory: builds, AI models, photo processing and game servers all want cores, and most VPS plans share their CPU with other customers, so very long runs at full load are better checked against your provider's fair-use rules first. Here are the 6 GB plans with the most 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 around 5.6 GB for your own software. Rough idle figures for what is in this guide (they vary a lot with version, settings and use, so measure your own with free -h and docker stats):

Service	Typical memory
GitLab with a runner and registry, small team	3 to 4.5 GB
Mailcow (with ClamAV)	3 to 4 GB
Mastodon with OpenSearch, small community	3 to 4 GB
A dozen small WordPress sites (nginx, PHP-FPM, MariaDB)	1.5 to 3 GB
Immich with machine learning	2.5 to 4 GB
Paperless-ngx with OCR	1 to 2 GB
PostgreSQL tuned for a busy app	1.5 to 3 GB
OpenSearch, one node, 1 to 2 GB heap	2 to 3.5 GB
n8n plus Metabase	1 to 2 GB
Gradle, Rust or Android builds	2 to 5 GB while building
k3d cluster, one server and two agents, before apps	1.5 to 2.5 GB
A 3B model on Ollama	2.5 to 3.5 GB
Cloud desktop (XFCE and a browser)	1 to 2 GB per session
Minecraft with a small modpack (4 to 5 GB heap)	4.5 to 5.5 GB

Three realistic combinations:

Setup	What runs	Roughly
Team platform	GitLab with a runner, Authentik, Uptime Kuma	4.5 to 5.5 GB
Private cloud for a family	Nextcloud, Immich with machine learning, Paperless-ngx, Vaultwarden	4.5 to 5.5 GB
Dev playground	PostgreSQL, a k3d cluster, a small model on Ollama, code-server	5 to 5.8 GB

Keep a 2 GB swap file as a safety net (steps are in the 1 GB guide). Swap matters most while installing and upgrading, when GitLab, Immich and container builds briefly need far more than they use afterwards. Before you add public services, secure the server and set up SSH keys. Most of what follows runs in containers, so install Docker and put a reverse proxy such as Caddy in front, as the 2 GB guide describes.

1. GitLab with CI and a registry

What it is. The full GitLab platform: Git hosting, merge requests, issue boards, CI/CD pipelines, a container registry and package repositories. The 4 GB guide ran it trimmed down, with no room for anything else. Here you can run it with its normal settings and a build runner next to it.

Why it suits 6 GB. GitLab on its own settles at around 3 to 4 GB. With 6 GB, you can leave its web workers and monitoring on, turn on the container registry, and run one CI job at a time on a runner in the same machine. GitLab's own sizing guidance grows with the number of users, and 6 GB is comfortable for a small team of a few people.

How to set it up. Install the Omnibus package from GitLab's repository, as its documentation describes for your distribution, set external_url, and then enable the registry with its own address in /etc/gitlab/gitlab.rb:

external_url 'https://git.example.com'
registry_external_url 'https://registry.example.com'
puma['worker_processes'] = 2
sidekiq['concurrency'] = 10

Run sudo gitlab-ctl reconfigure. Then install GitLab Runner from its repository, register it with the token from your project's settings, and choose the Docker executor. Limit it to one job at a time (concurrent = 1 in /etc/gitlab-runner/config.toml) so a pipeline cannot starve GitLab itself.

Watch out for. Upgrades are the memory spikes, so keep swap on. The registry and old pipeline artifacts fill the disk, so set expiry rules and run the registry's garbage collection now and then. Back up with sudo gitlab-backup create plus a copy of /etc/gitlab, and keep the copy off the server. Run the runner on a different machine as soon as builds get heavy.

2. A complete mail server

What it is. Email for your own domains with proper spam filtering and antivirus, webmail and a management interface. Mailcow is the best-known all-in-one: it packages Postfix, Dovecot, Rspamd, ClamAV and SOGo webmail as containers with an admin panel.

Why it suits 6 GB. Mailcow's documentation asks for around 6 GB of RAM, mostly because of the ClamAV virus scanner, and this is the smallest plan where you can leave everything on. At 4 GB people usually switch ClamAV off or choose a lighter server such as Stalwart, as the 4 GB guide describes.

How to set it up. Follow the Mailcow documentation: clone its repository into /opt, run ./generate_config.sh to choose your mail host name, then bring it up with sudo docker compose pull and sudo docker compose up -d. Then add your domains and mailboxes in the admin panel. Set the DNS records it shows you: MX, SPF, DKIM, DMARC, and the autodiscover entries. Ask your provider to set a reverse DNS (PTR) record that matches your mail host name.

Watch out for. The DNS and your server's reputation matter more than the software. Check that your provider allows outgoing mail on port 25, test a new address on a blocklist checker before depending on it, and warm up a new address slowly. Mailcow wants ports 80 and 443 for itself, so give it its own server or follow its guide for running behind a proxy. Back up the mailboxes and the DKIM keys, and keep it updated, since a mail server is attacked constantly.

3. A Mastodon community with search

What it is. A Mastodon server for a community or a company, with its own rules and moderation, joined to the wider Fediverse. The 4 GB guide ran a small instance without search. With 6 GB you can add full-text search through OpenSearch or Elasticsearch, and give the background workers room.

Why it suits 6 GB. A Mastodon instance (web, streaming, Sidekiq workers, PostgreSQL, Redis) uses roughly 2 to 3 GB, and the search service adds about 1 GB. That leaves some room for growth in a community of dozens to a few hundred active people.

How to set it up. Follow the project's production guide. It installs the Ruby app and its services directly or through containers, and walks through PostgreSQL, Redis, nginx, mail and certificates. Run OpenSearch with a limited heap (OPENSEARCH_JAVA_OPTS=-Xms512m -Xmx512m) and point Mastodon at it in its environment file.

Watch out for. Mastodon needs outgoing email, so use a transactional email service. Remote media and the database grow constantly, so set up the cleanup tasks the documentation describes and watch the disk. Pick the domain with care, since you cannot move it later without losing the identity of every account.

4. A small web host for clients

What it is. One server hosting a dozen or two websites, for yourself, a club, or a few clients, with a control panel so that adding a site, a certificate or a database is a few clicks. CloudPanel and HestiaCP are free panels that install on a clean Debian or Ubuntu server.

Why it suits 6 GB. A tuned stack serving small WordPress sites uses roughly 1.5 to 3 GB in total, much of it PHP-FPM workers and the database buffer pool. That is more than a 2 GB server can safely give to several sites at once, and 6 GB leaves space for traffic bursts and backups.

How to set it up. Install the panel on a fresh server by following its documentation, then add sites. Give each site its own PHP-FPM pool set to pm = ondemand, set innodb_buffer_pool_size to 1 GB or so, and add a page cache for each site, because caching does more for speed than any other change. The guide to installing WordPress on a VPS covers the basics, and web servers on a VPS covers the server side.

Watch out for. One site's problem can slow all of them, so watch for the outliers. Back up each site and its database nightly to somewhere else. Do not run mail on the same server, and keep every site's software updated. If you are thinking of selling hosting, read shared hosting versus reseller hosting first.

5. Immich with face recognition and smart search

What it is. The photo library from the 4 GB guide, with its machine-learning features on: faces are found and grouped by person, and you can search your photos by what is in them ("beach", "birthday cake"), not just by date.

Why it suits 6 GB. The project recommends about 6 GB. The machine-learning container needs a gigabyte or two on top of the rest, and it uses a lot of CPU when it first works through a library.

How to set it up. Use the compose file and .env from the project's latest release, keep the immich-machine-learning service in it, set UPLOAD_LOCATION to a folder with plenty of room, and set a strong database password. After the first upload, open the administration settings and lower the job concurrency so that face detection and smart search work through your library slowly, instead of using every core for days.

Watch out for. A large library can take many hours or days to process on a few shared cores, and that is normal. Photos need a lot of disk (see the list above). Read the release notes before each upgrade, because the project changes quickly, and back up both the database and the original files off the server.

6. A paperless office with Paperless-ngx

What it is. A document archive for scanned letters, receipts, contracts and manuals. You drop in a scan or a PDF, it reads the text with OCR, files it under tags and correspondents you define, and makes everything searchable. It is one of the most practical things a home or small-business server can do.

Why it suits 6 GB. The application, its database and Redis use roughly 1 to 2 GB, and OCR is the part that spikes: a big multi-page scan can use a lot of memory and CPU for a minute. Adding the optional converters for Office files makes it larger still.

How to set it up. Use the project's docker compose files, which run the app, PostgreSQL and Redis. To keep memory in check, limit the number of workers and threads in the environment settings (the variables are PAPERLESS_TASK_WORKERS and PAPERLESS_THREADS_PER_WORKER). Add documents through the web page, an email address it watches, or a shared consume folder that you copy files into with rsync.

Watch out for. A document archive holds the most private files you own, so put it behind a login, never leave it open, and use two-factor authentication. Back up both the originals and the database, and test restoring them. Set the OCR language to match your documents.

7. A production database server

What it is. A PostgreSQL server that real applications depend on, not only side projects, with settings tuned to the hardware, a connection pooler, and proper backups with point-in-time recovery.

Why it suits 6 GB. Databases are fast when they can keep their working data in memory. On 6 GB you can give PostgreSQL a buffer of around a quarter of the RAM and still leave room for the operating system's file cache, which it also relies on, and the application next to it.

How to set it up. sudo apt install postgresql, then in postgresql.conf set values in this range, and restart:

shared_buffers = 1536MB
effective_cache_size = 4GB
work_mem = 16MB
maintenance_work_mem = 256MB
max_connections = 100

Put PgBouncer in front if many clients connect. For backups, use a tool built for it, such as pgBackRest or WAL-G, that archives the write-ahead log to storage on a different machine, so you can restore to any moment. Keep PostgreSQL listening on localhost and reach it from elsewhere through an SSH tunnel or a VPN.

Watch out for. A backup you have never restored is a guess, so practise a restore. Do not expose the port to the internet. A single VPS is one failure away from losing everything, so decide how much downtime you can accept. Treat the tuning numbers as a starting point and measure with your own workload.

8. A search and log platform

What it is. OpenSearch (or Elasticsearch) as a single-node search and analytics engine: it can store logs from all your servers for searching and graphing, or power search for a big website or app.

Why it suits 6 GB. These engines are Java programs that want a large fixed heap (the usual advice is to give about half of what the machine can spare, and not more) and extra memory outside the heap for file caching. A node with a 1 to 2 GB heap uses 2 to 3.5 GB, which only works comfortably on a plan like this one.

How to set it up. Raise the kernel limit it needs, then run it in a container with a limited heap:

sudo sysctl -w vm.max_map_count=262144
echo 'vm.max_map_count=262144' | sudo tee /etc/sysctl.d/99-opensearch.conf

  opensearch:
    image: opensearchproject/opensearch:2
    environment:
      - discovery.type=single-node
      - OPENSEARCH_JAVA_OPTS=-Xms1g -Xmx1g
      - OPENSEARCH_INITIAL_ADMIN_PASSWORD=choose-a-long-password-1A!
    ports: ["127.0.0.1:9200:9200"]
    mem_limit: 2500m
    volumes: ["os_data:/usr/share/opensearch/data"]

Ship logs into it with an agent such as Fluent Bit or Vector, and view them in OpenSearch Dashboards or Grafana. Set a retention policy so old indices are deleted automatically.

Watch out for. Never expose the port to the internet. Logs fill disks quickly, so rotate and expire. A single node has no replica, so keep a copy of anything you cannot recreate. If you only need to search a site's content, Meilisearch from the 4 GB guide is far lighter.

9. Automation and dashboards: n8n and Metabase

What it is. n8n is a visual workflow tool, a self-hosted alternative to the paid automation services. It connects apps and runs flows on a schedule or when something happens: copy form entries into a spreadsheet, post alerts to chat, process incoming data. Metabase turns a database into charts and dashboards that non-programmers can use.

Why it suits 6 GB. n8n uses a few hundred megabytes, and Metabase is a Java program that wants around a gigabyte of heap, plus a PostgreSQL database for each of them. Together with the database they use roughly 1 to 2 GB, which leaves the rest of a 6 GB server for the apps they read from.

How to set it up. Run both in one compose file with PostgreSQL, behind Caddy. For n8n set N8N_ENCRYPTION_KEY to a long random value and keep it safe, because it protects the credentials you store. For Metabase, store its own data in PostgreSQL rather than the built-in file database, and set JAVA_OPTS=-Xmx1g. Create read-only database users for Metabase so a mistake cannot change your data.

Watch out for. Automations can fail silently, so send failures to your phone or chat. Treat the stored credentials as the keys to every service they connect to. Back up both applications' databases.

10. A build server for heavy projects

What it is. A machine that compiles big things so your laptop does not have to: Java and Kotlin with Gradle, Android apps, large Rust or C++ projects, Docker image builds, or a self-hosted CI runner.

Why it suits 6 GB. Builds use memory in bursts. The Gradle daemon alone wants 1 to 2 GB, and a full Android build or a Rust build with link-time optimisation can use 3 to 5 GB. At 2 GB or 4 GB these are killed halfway through, and at 6 GB they finish.

How to set it up. Set limits so a build can never use everything: org.gradle.jvmargs=-Xmx2g in gradle.properties, cargo build -j 2 for Rust, and one concurrent job in your CI runner. Cache dependencies and compiled output (ccache or sccache) so repeat builds are quick, and keep the swap file on. Run the work from tmux or a systemd service so it survives a dropped connection.

Watch out for. A sustained run at full CPU on shared cores is the kind of workload providers watch for, so check your provider's fair-use rules, and use fewer jobs rather than more. Build caches and Docker layers fill the disk, so run docker system prune regularly. Do not run a CI runner that accepts jobs from strangers' pull requests on a server that holds anything private.

11. A multi-node Kubernetes lab

What it is. A realistic cluster for learning or testing: one control-plane node and two or three workers, so you can practise rolling updates, node failures, scheduling and networking. The nodes are containers, created by k3d (k3s in Docker) or kind.

Why it suits 6 GB. The 2 GB guide ran a single k3s node. A three-node k3d cluster uses 1.5 to 2.5 GB before your own apps, and leaves 3 GB for the workloads you want to test.

How to set it up. With Docker installed and k3d from its releases:

k3d cluster create lab --servers 1 --agents 2 \
  -p "8080:80@loadbalancer"
kubectl get nodes

Deploy a sample app with a manifest, expose it through the built-in ingress, then try breaking things: delete a pod, drain a node, roll out a bad image and roll it back. Delete the whole cluster with k3d cluster delete lab and start again whenever you like.

Watch out for. This is a learning and testing tool, not a way to run production, because all the nodes share one machine and one failure. Set resource requests and limits on every workload, since the cluster has no spare capacity to hide a mistake.

12. Small AI models on your own server

What it is. A language model running on your own machine, so what you type never leaves it. Ollama downloads and runs open models, and Open WebUI gives you a chat page in the browser. The same server can run embedding models for search over your own documents, or a small speech-to-text model.

Why it suits 6 GB. A model with about 3 billion parameters, quantised to 4 bits, needs roughly 2 to 3 GB of memory, which fits beside a few other services. Larger models (7 to 8 billion parameters) need around 5 GB or more and are only possible with nothing else running.

How to set it up. Install Ollama from the project's instructions, pull a small model, and try it:

ollama pull llama3.2:3b
ollama run llama3.2:3b

Keep Ollama listening on 127.0.0.1 and reach it through Open WebUI behind Caddy with a login, or through an SSH tunnel.

Watch out for. Be realistic. With no graphics card and a few shared cores, a small model answers at a few words per second and is much less capable than the big hosted ones. It suits private notes, summaries, classification and experiments, not complex reasoning. It also keeps the CPU busy while generating, so check your provider's fair-use rules and do not leave it running flat out. Never expose the Ollama port to the internet.

13. A cloud desktop

What it is. A full Linux desktop that you reach from any computer, a tablet or a Chromebook. Your browser, editor, terminals and files are always where you left them, on a server with a fast connection.

Why it suits 6 GB. A light desktop such as XFCE uses 300 to 500 MB, and a browser and an editor each add several hundred more, so one session with a few apps uses 1 to 2 GB. On 6 GB you can run a desktop next to your other services.

How to set it up. Install a light desktop and an RDP server, and connect through an SSH tunnel so that the port is never public:

sudo apt install xfce4 xfce4-goodies xrdp
sudo systemctl enable --now xrdp
# on your own computer:
ssh -L 3389:127.0.0.1:3389 user@your_server_ip

Then point a remote-desktop client at localhost:3389 and sign in with your server user. Web-based options such as Apache Guacamole or KasmVNC give you the same desktop inside a browser tab.

Watch out for. Never expose an RDP port to the internet: it is scanned and attacked within minutes. Pick a location near you, because latency decides how pleasant it feels. A VPS has no graphics card, so video playback and 3D are poor, and it suits work, not entertainment.

14. An everything box

What it is. One server running twenty or more small and medium services, the way a home lab does: a reverse proxy, single sign-on, a cloud, a password manager, a wiki, monitoring, a few automations and a handful of experiments.

Why it suits 6 GB. This is where the budget table pays off. Services that each need 100 to 500 MB add up, and 6 GB is the first size where you can run Authentik, Nextcloud, Vaultwarden, a wiki, Uptime Kuma, Grafana with Loki and a few more together without constantly worrying.

How to set it up. Keep each stack in its own folder with its own compose.yaml, joined by a shared Docker network, with Caddy in front. Give every container a limit (mem_limit: 500m) so one runaway cannot take the rest down, and check where the memory goes:

sudo docker stats --no-stream --format "table {{.Name}}\t{{.MemUsage}}\t{{.CPUPerc}}"

Write down what runs and why, and keep your configuration in a Git repository, so you can rebuild the server in an afternoon.

Watch out for. Every extra service is more to update and more to attack. Update on a schedule, remove things you stopped using, and keep full off-server backups of the data volumes. Look at self-hosted apps and what they need before adding something big.

15. Modded Minecraft and bigger game servers

Minecraft with mods. A Fabric or Forge server with a small to medium modpack, or a plugin-heavy Paper server for a larger community, needs a heap of 4 to 5 GB:

java -Xms4G -Xmx5G -jar server.jar --nogui

That leaves a little under 1 GB for the system, which is tight, so use no other heavy service on the same server. Minecraft depends mostly on one fast CPU core, so a plan with fast cores matters more than a high core count. Large modpacks often want 8 GB or more, so check the pack's own recommendation.

Other games. Project Zomboid and a modded Valheim server fit comfortably. Satisfactory is officially recommended at 8 GB, and may start on 6 GB with a small save and swap, but expect trouble as the factory grows. ARK, Rust, Palworld and 7 Days to Die want 8 GB to 16 GB and more.

Watch out for. Choose a location near your players (see the list above), run the server in tmux or a systemd service, and open only the game's ports. Back up the world folder every day, because worlds are lost to crashes and to mistakes. More in VPS plans for game servers.

What does not fit in 6 GB

• Large language models. Models of 13 billion parameters and above need 10 GB or more, and good speed needs a graphics card.
• Big game servers: Rust, ARK, Palworld and a grown Satisfactory factory.
• GitLab for a big team, or one that also hosts heavy CI on the same machine.
• Several heavy platforms together. Mailcow, Immich with machine learning and GitLab each take most of a 6 GB server alone, so pick one or two.
• Large Elasticsearch clusters and big data stores. A single node is fine for logs and site search, but not for clustered, replicated setups.
• Anything that needs high availability. One VPS is one failure away from downtime, whatever its size.

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, models and games slow down because every core is busy. The next step, 8 GB, is where a mail server and a code platform can share a machine, where 7 to 8 billion parameter models become possible if nothing else is running, and where modded Minecraft and games like Satisfactory stop being a squeeze. 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.