What can you do with an 8 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, 4 GB and 6 GB. This is the last in the series.

Eight gigabytes is the top of the VPS range, and it is enough to run things most people assume need a dedicated server. A company's code platform, mail and files on one machine. A video platform. A local language model with a real retrieval setup over your own documents. A security monitoring system. A database cluster to practise failure on. Game servers that refuse to start on anything smaller. This guide covers fifteen uses for an 8 GB plan, what each one really needs, how to set it up, and the honest limits, including the point where you should stop adding to one server and move to a dedicated server or split the work.

What is in this guide

• What an 8 GB VPS gives you and your memory budget
• Run a small organisation: a code platform for a company, mail, files and video together, a Matrix chat server with bridges, business software (ERPNext or Odoo), a busy WooCommerce shop
• Data and intelligence: a local language model with your documents, ClickHouse for analytics, full observability, security monitoring with Wazuh, a video platform
• Labs: many servers on one with Incus, a database cluster lab, a GitOps platform lab
• Games: a game hosting panel and heavy game servers
• One big server or several small ones?, what does not fit in 8 GB and when to step up

What an 8 GB VPS gives you

Plans in this class usually have four or more CPU cores, 8 GB of RAM, 150 GB or more of disk and several terabytes of bandwidth. Check the listing, because they differ. At this size the CPU is shared with other customers on the same host, so long runs at full load are worth checking against your provider's fair-use rules first. Here are the 8 GB plans with the most cores, and those with the most disk:

Your memory budget

A fresh Debian or Ubuntu server uses 100 to 250 MB idle, which leaves about 7.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 two runners and a registry	3.5 to 5.5 GB
Mailcow plus Nextcloud	4 to 5.5 GB
Matrix Synapse with PostgreSQL and a few bridges	1.5 to 3 GB
ERPNext or Odoo for a small company	2 to 4 GB
WooCommerce stack with Redis and a page cache	2 to 4 GB
A 7 to 8B language model on Ollama	5 to 6 GB
ClickHouse (limited)	2 to 5 GB
Prometheus, Loki, Tempo and Grafana	1.5 to 3 GB
Wazuh all-in-one	5 to 7 GB
PeerTube with a transcoding job running	2 to 4 GB
Incus: ten small system containers	2 to 6 GB, set by you
Pterodactyl or Pelican panel, before game servers	0.8 to 1.5 GB
Rust or ARK server	5 to 8 GB

Three realistic combinations:

Setup	What runs	Roughly
Small company in a box	Mailcow, Nextcloud, Authentik, Vaultwarden, Uptime Kuma	6 to 7.2 GB
Private AI desk	Ollama with an 8B model, Open WebUI, Paperless-ngx	6.5 to 7.5 GB
Community game host	A Pterodactyl panel with two or three game servers	6 to 7.5 GB

Keep a 2 GB swap file as a safety net (steps are in the 1 GB guide), but do not plan to live in it: swap on a VPS disk is far slower than memory. 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. A code platform for a company

What it is. GitLab as a company's single home for code: repositories, reviews, issue boards, CI/CD pipelines, a container registry, package repositories and built-in security scanning options. The 4 GB guide ran it trimmed, and the 6 GB guide ran it with one runner. Here you can serve a real team.

Why it suits 8 GB. GitLab on its own settles around 3 to 4 GB, and that leaves 3 to 4 GB for two CI runners that build and test code at the same time. GitLab's own sizing guidance grows with the number of users, and 8 GB is comfortable for a team of a few dozen people with moderate use.

How to set it up. Install the Omnibus package as its documentation describes, set external_url and registry_external_url, set up outgoing email through SMTP, and run sudo gitlab-ctl reconfigure. Install GitLab Runner, register two runners, and set concurrent = 2 in /etc/gitlab-runner/config.toml. Add a memory limit to each runner's Docker settings so a test run cannot take more than its share.

Watch out for. Artifacts, caches and registry images are what fill the disk, so set expiry rules and clean up. Plan the upgrade path, since GitLab requires you to move through certain versions in order, and read its upgrade notes first. Back up with sudo gitlab-backup create and a copy of /etc/gitlab, stored off the server. If builds get heavy, move the runners to their own machine.

2. Mail, files and video for a small company

What it is. The services a small business buys from a big supplier, on one server you control: email with spam and virus filtering and webmail (Mailcow), shared files, calendars and contacts (Nextcloud), and video meetings (Jitsi Meet), all behind a single sign-on if you like.

Why it suits 8 GB. Mailcow alone wants around 6 GB in its documentation when ClamAV is on. Nextcloud takes another gigabyte or so, which is why this combination did not fit in 6 GB. At 8 GB you have to be disciplined, but it works: Mailcow and Nextcloud together use 4 to 5.5 GB, and Jitsi is best left for small meetings or run on its own server.

How to set it up. Let Mailcow keep the mail ports, and put your own reverse proxy in front for the web services. Mailcow's documentation has a section on running behind a proxy: you change the web ports in mailcow.conf (HTTP_PORT, HTTP_BIND, HTTPS_PORT, HTTPS_BIND) and let your proxy handle the certificates. Run Nextcloud in its own container behind the same proxy, as in the 2 GB guide. Give every container a memory limit.

Watch out for. Mail is the part that needs care: reverse DNS, SPF, DKIM, DMARC, a clean server address, and a provider that allows outgoing mail on port 25. Test with a blocklist checker before you move real mail. Keep the whole stack updated and back up the mailboxes, the DKIM keys and the Nextcloud data and database separately.

3. A Matrix chat server with bridges

What it is. Your own chat service for an organisation or community, on the open Matrix network, with rooms, threads, end-to-end encryption and apps for every platform. Bridges connect it to other services, so people on Telegram, Discord or Signal can talk to people on your server in the same room.

Why it suits 8 GB. Synapse, the main server, uses 1 to 3 GB depending on the rooms your users join, plus PostgreSQL, and each bridge adds 50 to 150 MB. The memory use climbs sharply if your users join very large public rooms, so you need headroom.

How to set it up. The easiest complete route is the community-maintained Ansible playbook for Matrix (often called matrix-docker-ansible-deploy), which installs Synapse, PostgreSQL, Element, a reverse proxy, and your choice of bridges from one configuration file. Use PostgreSQL, not the default SQLite, and set up regular database backups.

Watch out for. Public rooms with thousands of members from other servers make the database and memory grow, so ask your users to stay in private or smaller rooms, or set a retention policy. The domain you choose cannot easily change later. Keep Synapse updated, because it is a public target.

4. Business software: ERPNext or Odoo

What it is. A complete business system: accounting, invoicing, inventory, purchasing, sales, projects and in some cases HR and a website. ERPNext and Odoo Community are the two big open-source choices.

Why it suits 8 GB. These are large Python applications with a database behind them. Their documentation asks for around 4 GB as a minimum for ERPNext, and both get slow when many people use them at once, because each worker process takes a few hundred megabytes. 8 GB lets you run enough workers and a properly sized database.

How to set it up. For ERPNext, use the project's Docker setup (frappe_docker) or the bench installer on a clean server, and follow its production steps. For Odoo, install the package or container, set workers to about two per CPU core, and set memory limits in odoo.conf so a runaway process is restarted rather than taking the server down. Put it behind HTTPS and a firewall, and create a backup job straight away.

Watch out for. This holds your accounts, so backups that you have restored at least once matter more here than anywhere else in this guide. Customisation and upgrades are real work, and are where most of the cost of these systems lies. Test an upgrade on a copy first.

5. A busy WooCommerce shop

What it is. An online shop that holds up under real traffic. WooCommerce is the popular WordPress shop plugin, but a shop cannot be cached as aggressively as a blog, because carts, logged-in customers and checkout are different for every visitor.

Why it suits 8 GB. You can give the database a large buffer, run more PHP workers for the uncached pages, add a Redis object cache, and still have room for traffic spikes. A tuned stack uses 2 to 4 GB, and what is left absorbs a sale day.

How to set it up. Start from the WordPress install guide, then tune: innodb_buffer_pool_size = 2G for MariaDB, PHP-FPM with pm = dynamic and a pm.max_children your memory can afford (each uncached request uses 60 to 150 MB), OPcache at 256 MB, a Redis object cache limited to 256 MB, and a page cache that skips the cart, checkout and account pages. Turn off WordPress's built-in scheduler (define('DISABLE_WP_CRON', true);) and run a real cron job every minute instead.

Watch out for. Use a hosted payment page, such as the one your payment provider offers, so card details never touch your server. Load-test before a sale, not during it. Keep the plugin list short, keep everything updated, and back up the database every night. See web servers on a VPS for the server side.

6. A local language model with your own documents

What it is. A 7 to 8 billion parameter language model running on your server through Ollama, with Open WebUI as the chat page, set up so that it can answer questions about your own files. Your documents are split up, turned into numbers (embeddings) and stored in a vector database, and the model is given the relevant pieces with each question. This is usually called retrieval-augmented generation, or RAG.

Why it suits 8 GB. An 8B model quantised to 4 bits needs around 5 to 6 GB, and a longer conversation needs more for its context. That is possible only on a server that does little else. The 6 GB guide stopped at 3B models.

How to set it up. Install Ollama, then pull a chat model and an embedding model:

ollama pull llama3.1:8b
ollama pull nomic-embed-text

Run Open WebUI in a container behind Caddy with a login. It has built-in document upload and search, which uses the embedding model. Limit Ollama to one model at a time and one request at a time with the environment settings OLLAMA_MAX_LOADED_MODELS=1 and OLLAMA_NUM_PARALLEL=1.

Watch out for. Be realistic about speed. With no graphics card, an 8B model answers at a few words per second at best, and the first words come slowly after a long question. It suits private summaries, questions over your own notes and batch jobs that can run overnight, not a fast assistant. It uses the CPU hard while generating, so check your provider's fair-use rules. Keep the Ollama port private.

7. ClickHouse for serious analytics

What it is. A column-oriented database built to answer questions over hundreds of millions of rows in seconds: web and product analytics, logs, sensor data, financial history, anything where you count and group a lot of data. It is also what several privacy-friendly analytics products use underneath.

Why it suits 8 GB. ClickHouse is happy to use every bit of memory you give it for caching and for large queries, so it needs room, and a cap on how much of it can have. With 8 GB you can give it half and still run the apps that feed it.

How to set it up. Install the server and client from the project's package repository, set a memory ceiling in its configuration (the max_server_memory_usage_to_ram_ratio setting, for example 0.5), and create a table:

CREATE TABLE events (
  ts DateTime, user_id UInt64,
  event LowCardinality(String), value Float64
) ENGINE = MergeTree ORDER BY (event, ts);

SELECT event, count() FROM events
WHERE ts > now() - INTERVAL 7 DAY GROUP BY event ORDER BY 2 DESC;

Load data in batches (thousands of rows at a time, not one by one), and connect Grafana or Metabase for charts.

Watch out for. ClickHouse is not a replacement for a normal database: it is poor at frequent single-row updates. Keep its ports private. Back up with the project's backup tools or by copying the data directory while it is stopped, and plan disk size for the growth of your data.

8. Full observability: metrics, logs and traces

What it is. The 4 GB guide had metrics, logs and uptime checks. This adds traces: a record of how a single request travelled through your services and where the time went. Prometheus collects metrics, Loki keeps logs, Tempo keeps traces, and Grafana shows all three side by side, so you can jump from a slow graph to the logs and the trace behind it.

Why it suits 8 GB. Each piece is modest, but together with long retention and a few busy services they use 1.5 to 3 GB. You also still want room for the apps being watched.

How to set it up. Run all four in a compose file with a memory limit on each, and send data to them through Grafana Alloy or the OpenTelemetry Collector, which receives metrics, logs and traces from your applications in one place. Keep 15 to 30 days of metrics, 7 to 14 of logs and 3 to 7 of traces, and set alerts to go to your phone.

Watch out for. Traces and logs multiply fast, so use sampling for traces and retention for everything. Keep all the ports private. As ever, a monitor is only useful if it runs somewhere other than the servers it watches, so put an uptime check on a second provider.

9. Security monitoring with Wazuh

What it is. An open-source security platform that watches your servers for trouble: failed and successful logins, changed system files, rootkits, vulnerable packages, suspicious processes and configuration problems. A small agent on each server reports to a central manager, and a dashboard shows alerts.

Why it suits 8 GB. The all-in-one install runs the manager, an OpenSearch-based indexer and a dashboard on one machine, and the indexer is the heavy part. Wazuh's documentation gives sizing by the number of agents, and 8 GB is the small end of the all-in-one install, so it is meant for a handful of servers and not a large fleet.

How to set it up. Use the assisted installer from the Wazuh documentation (download it and read it before you run it as root), then install the agent on every server you want to watch. Give the indexer a fixed heap so it cannot use everything, and set retention for old alerts.

Watch out for. It will raise a lot of alerts at first, so tune the rules and decide which ones you will act on, or you will ignore them all. Keep the dashboard private, behind a VPN or a login. A monitoring server that holds the logs of everything else is itself a valuable target, so keep it patched.

10. A video platform with PeerTube

What it is. Your own YouTube-style site for a school, a club, a channel or a company: upload videos, publish them on channels, with comments, playlists and live streaming, and optionally join the federated PeerTube network so other servers can show your videos.

Why it suits 8 GB. The application, PostgreSQL and Redis use 1 to 2 GB, but PeerTube converts every upload into several resolutions with ffmpeg, which takes several cores and a couple of gigabytes while it runs.

How to set it up. Install it with the project's Docker or native guide. In the admin settings, limit transcoding to the resolutions you need (for example 480p and 720p), set transcoding concurrency to 1 and its threads to fewer than your cores, and turn off options you do not want, such as automatic copies of other servers' videos.

Watch out for. Video is the most expensive thing in this guide in disk and bandwidth, so choose a plan with plenty of both, and check your allowance against what viewers will watch. Transcoding is also sustained heavy CPU use, so check your provider's fair-use rules. Moderate what is uploaded, because you are responsible for it.

11. Many servers on one, with Incus

What it is. Incus (a community fork of LXD) runs full Linux system containers: each one behaves like its own small server, with its own users, services, network address and firewall, but they share the host's kernel, so they cost far less than virtual machines. You can have ten or twenty on one VPS.

Why it suits 8 GB. A small Debian container idles at 20 to 60 MB, so you can run a separate "server" for each project, customer or experiment and give each a hard limit. It is a good way to practise server administration and to keep unrelated work apart.

How to set it up. Incus is packaged in recent Debian and Ubuntu releases. Install it, initialise it, and launch containers with limits:

sudo apt install incus
sudo incus admin init --minimal
incus launch images:debian/12 web1 -c limits.memory=1GiB -c limits.cpu=1
incus list
incus exec web1 -- bash

Change a limit later with incus config set web1 limits.memory 512MiB, take a snapshot before risky changes with incus snapshot create web1 before-upgrade, and copy containers between servers with incus copy.

Watch out for. Docker and Incus on the same host fight over the firewall rules, so read the Incus documentation on that before mixing them. Containers share the host's kernel, so they are weaker isolation than virtual machines. Full virtual machines inside a VPS need nested virtualisation, which many providers do not enable: check whether /dev/kvm exists before counting on it.

12. A database cluster lab

What it is. A set of database servers set up the way a production system would be: PostgreSQL with automatic failover (using Patroni and etcd, or the simpler pg_auto_failover), a Redis setup with Sentinel, or a MongoDB replica set. The point is to watch what happens when a node dies.

Why it suits 8 GB. A realistic cluster is three to five processes, each of which takes 300 to 600 MB with a small data set, plus a load balancer such as HAProxy. They run as containers on one machine, and 8 GB is the first size where that is comfortable.

How to set it up. Use the compose examples in each project's documentation, start the cluster, load some sample data, and then break things on purpose: stop the primary's container (docker stop), watch a replica get promoted, and check that your application reconnects. Then restore the old primary as a replica.

Watch out for. This is a learning and testing tool. All the nodes share one machine and one disk, so it gives no real protection against failure. It does teach you what to monitor, how to back up, and what your application does when the database is gone.

13. A GitOps platform lab

What it is. A small version of how larger companies run Kubernetes: a cluster whose state is defined in a Git repository and kept in sync automatically by Argo CD or Flux, with monitoring and an ingress controller on top. Change a file, push it, and the cluster follows.

Why it suits 8 GB. A multi-node k3d cluster (see the 6 GB guide) uses 1.5 to 2.5 GB, and Argo CD with a monitoring stack adds 1.5 to 2.5 GB more. That still leaves room for the sample applications you deploy.

How to set it up. Create the cluster with k3d cluster create gitops --servers 1 --agents 2, install Argo CD from its documentation, and create a Git repository that holds your application manifests. Point an Argo CD application at it, then install a monitoring stack by Helm and try an upgrade, a rollback and a deliberate failure. Your repository on your own Git server works as the source.

Watch out for. This is for learning and testing, not production. Set resource requests and limits on everything, because the cluster has no spare capacity to hide a mistake. Delete and rebuild the cluster often; being able to do that is the whole point of GitOps.

14. A game hosting panel

What it is. A web panel that manages many game servers on one machine, each in its own container with its own memory and CPU limit, its own ports, a console, a file manager, scheduled restarts and backups, and logins for the people who run them. Pterodactyl and its successor Pelican are the well-known open-source panels.

Why it suits 8 GB. The panel and its database use 0.8 to 1.5 GB, and the rest is divided among game servers that you cap individually: for example a 3 GB Minecraft server and a 2 GB Valheim server. It is the tidy way to run several games for a community, and to give your friends control of theirs without giving them shell access.

How to set it up. Follow the project's installation guide: a web server, PHP, MariaDB and Redis for the panel, then Docker and the Wings daemon on the node that hosts the games. Add the node in the panel, create allocations (the ports), and create servers from "eggs", which are ready-made definitions for each game.

Watch out for. The panel is a high-value target, so keep it and Wings updated, put it behind HTTPS and two-factor authentication, and keep it off the public list of services you advertise. Check your provider's terms before you sell or rent game servers to other people, because many VPS plans do not allow reselling.

15. Heavy game servers

What fits. Eight gigabytes is the first size where several demanding servers become possible: Rust, ARK, Satisfactory, 7 Days to Die, a big Minecraft modpack with a 6 to 7 GB heap, or a network of Minecraft servers behind a Velocity proxy. Most of these publish memory recommendations that start around 8 GB.

How to set it up. Install the game's dedicated server with SteamCMD (find the application number in the game's server documentation), run it under its own unprivileged user, open only its ports, and run it in tmux or as a systemd service, or let the panel from idea 14 do all of this for you:

steamcmd +force_install_dir /opt/game +login anonymous \
  +app_update APP_ID validate +quit

For Minecraft, a pack that wants a large heap looks like this, which leaves about 1 GB for the system:

java -Xms6G -Xmx7G -jar server.jar --nogui

Watch out for. Memory use of these games grows with the map, the number of players and how long the server has been running, so schedule a restart every day. Rust and ARK are often recommended at 8 to 16 GB for a busy server, and Palworld's own recommendation is 16 GB, so on 8 GB expect to cap the player count and restart often. Game servers care about CPU speed and the distance to your players, so choose the nearest location (see the list above). Back up the world files daily. More in VPS plans for game servers.

One big server or several small ones?

An 8 GB plan can do the work of several small ones, and often costs less than they would. But it is also a single point of failure, and one busy service can starve all the others. Some rules of thumb:

• Put things on one server when they belong together, when a short outage is acceptable, and when you want to keep costs and maintenance low.
• Split them up when one is sensitive (mail, a password manager, your backups) and another is risky (a public game server, a build runner), when one needs a different location, or when a failure in one would be costly for the others.
• Never keep the only copy of your backups on the same server as the data. Use a second, smaller plan (the 1 GB guide has ideas) as a backup and monitoring box, in a different location.

What does not fit in 8 GB

• Large language models. Models of 13 billion parameters and above need 10 GB or more, and any model worth using interactively really needs a graphics card, which a VPS does not have.
• Big data bigger than memory and disk. A single node cannot hold or scan terabytes.
• High availability. One VPS is one failure away from downtime, however big. Clusters need several machines in several places.
• Large game communities. A popular Rust, ARK or Palworld server wants 16 GB and fast cores.
• Video transcoding at scale, live streaming to many viewers, or anything that needs a graphics card.
• Everything at once. Wazuh, Mailcow, GitLab and an AI model each want most of an 8 GB server. Pick two at most.

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

When to step up

Move on when swap is in constant use, when the kernel kills programs for lack of memory (dmesg | grep -i oom will show it), or when every core is busy for hours. At this size the next step is usually not a bigger VPS but a different kind of machine: a dedicated server with its own hardware, more cores and no neighbours, or several servers that share the work. Moving is simple: set up the new server, restore your configuration and data, and switch your domain over.

That completes the series. If you are choosing between sizes, the 2 GB, 4 GB and 6 GB guides each show what the next step down gives you, and the cheapest VPS plans right now page lists the lowest prices at any size. The sales calendar shows when the best deals of the year arrive.