VPS for an IT Services Company: What Specs Actually Matter

The first time you run a client's automation stack on a VPS, you learn fast what "IT services company" actually means: you are not hosting a website, you are running a small data center for one client. n8n workflows, a GitLab runner, a mail relay, a Docker registry, maybe a monitoring stack. All on one box, all with your name on the SLA. This post walks through what an IT services company should look for in a VPS for client work, with concrete specs and commands you can run today. It applies to any Linux distribution, but the examples target Ubuntu 24.04 LTS, which is what most providers, including Linux VPS plans, offer by default.

Prerequisites

• A VPS running Ubuntu 24.04 LTS or Debian 12, with root or sudo access.
• A domain name if you plan to expose web UIs or receive mail.
• SSH key access configured before you start (see how to connect to a Linux VPS over SSH for the first time).
• Basic familiarity with systemd, Docker, and the command line.

What an IT services company actually runs on a VPS

An IT services company is not a typical VPS customer. You are not running one WordPress site. You are running the internal tools that deliver your services: workflow automation, CI/CD pipelines, customer portals, mail relays, and monitoring. Each of these has different resource demands, and they share one box.

The mistake most people make is sizing the VPS for the heaviest single workload and ignoring the fact that these tools run concurrently. A GitLab runner idles at almost nothing until a pipeline fires, then it wants four cores. n8n sits at 200 MB of RAM until a workflow with 50,000 records runs, then it wants 2 GB. A mail relay is quiet all day, then a client sends a campaign and you watch the queue grow.

This is why the RAM and vCPU counts matter less than the shape of the workload. For an IT services company, the practical choice is usually a mid-range VPS with 4 to 8 GB of RAM, 2 to 4 vCPUs, and NVMe storage, sized to handle the concurrent peak, not the average. A VPS designed for n8n workflows is a good starting point, then you add the other services around it.

Step 1 - Choose the right OS and virtualization

For an IT services company, the OS choice is rarely about preference and almost always about the toolchain. Most automation and CI/CD tools run best on Linux, and Ubuntu 24.04 LTS or Debian 12 covers nearly everything. If you have Windows-only clients or legacy .NET workloads, you need a Windows VPS instead, but expect to pay double for the RAM.

What matters more is the virtualization layer. You want KVM, not OpenVZ or LXC. KVM gives you a real kernel, real swap, and the ability to run Docker and systemd modules without restrictions. You can verify the virtualization type from inside the box:

systemd-detect-virt

Expected output on a KVM VPS:

kvm

If it returns openvz or lxc, you are on container virtualization, and Docker or swap-heavy workflows will bite you later.

Step 2 - Size RAM and vCPU for the real workload

Here is the sizing rule I use for IT services workloads. It is a starting point, not gospel, but it has held up across many client setups.

Add these up and you get 6.75 GB just for the baseline. That is why a 4 GB VPS feels tight and an 8 GB VPS feels comfortable. If you are running everything for one or two clients, a 4 GB VPS with swap will survive, but for three or more clients, step up to 8 GB.

On a thueVPS plan, the VNx4 (4 vCPU, 8 GB RAM, NVMe) is the sweet spot for an IT services company with a few active clients. The VNx2 (2 vCPU, 4 GB) works if you are disciplined about what you run, and the VNx8 (8 vCPU, 16 GB) is for when you have multiple clients with concurrent CI/CD pipelines. All run on NVMe storage, which matters more than vCPU count for database and queue workloads.

Step 3 - Set up swap and verify memory behavior

Even with enough RAM, swap is a safety net. A runaway workflow or a memory leak in a client's script should not OOM-kill your n8n instance. Set up a swap file on Ubuntu 24.04:

fallocate -l 2G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile
echo '/swapfile none swap sw 0 0' >> /etc/fstab

Verify it is active:

swapon --show

Expected output:

NAME      TYPE SIZE USED PRIO
/swapfile file   2G   0B   -2

Then check what is actually consuming RAM. I keep a habit of running this after every deployment:

ps aux --sort=-%mem | head -20

If a single process is eating more than 40% of RAM, that is a problem to fix, not a reason to buy more RAM. Track it with Prometheus and Grafana before you upgrade.

Step 4 - Run Docker workloads with Compose v2

For an IT services company, Docker is the default way to run client tools. n8n, GitLab runner, Redis, Postgres, all of them have clean images, and Compose v2 files make a client's stack reproducible.

Install Docker and the Compose plugin on Ubuntu 24.04:

apt update
apt install -y docker.io docker-compose-v2
systemctl enable --now docker

Verify the Compose v2 syntax works:

docker compose version

Expected output:

Docker Compose version v2.x.x

Then structure your stack in /opt/clientname/ with one docker-compose.yml per client. Keep each client's data in its own volume so backups and restores stay isolated. For the networking details, see Docker networking explained: bridge, host, overlay, because getting bridge vs host wrong is the most common source of breakage when you add a reverse proxy later.

Step 5 - Secure the box before connecting client tools

The moment you expose n8n or a GitLab runner to a client, the box becomes a target. The minimum baseline for an IT services VPS is the same as for any production server, and it is covered well in hardening SSH on a new VPS. The short version: disable root login, use ED25519 keys, change the SSH port, and set up fail2ban.

sed -i 's/^#PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config
systemctl restart ssh

Then enable the ufw firewall and allow only what you need:

ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable

Do not open port 25 unless you are running a mail relay for a client, and if you are, see the SPF/DKIM/DMARC guidance in configure SPF, DKIM and DMARC on a mail VPS. A mail relay without proper DNS records is a blacklist ticket waiting to happen.

Step 6 - Backups and snapshots are not optional

You are hosting client data. A lost workflow or a corrupted GitLab repo is not an inconvenience, it is a breach of trust. Use the VPS provider's snapshot feature as the first line of defense, and schedule it. On most KVM providers, including thueVPS, snapshots are a one-click operation from the control panel, and they capture the full disk state.

But snapshots are not backups. A snapshot lives on the same infrastructure as the VPS. For real redundancy, pull critical data off-box. A simple cron job that dumps Postgres and tars the n8n .n8n directory to an off-site location covers most cases:

pg_dump -Fc clientdb > /backups/clientdb.dump
tar czf /backups/n8n-$(date +%F).tar.gz /root/.n8n

Test the restore path at least once a month. A backup you have never restored is a guess, not a backup. See how to create and restore a VPS snapshot on KVM for the full workflow.

Why a Vietnam IPv4 matters for an IT services company

越南 VPS 提供本地 IPv4，适合面向越南用户的业务。

A Vietnam VPS gives you a local IPv4, which suits services aimed at users inside Vietnam.

If your clients are in Vietnam, or if you are managing systems that talk to Vietnamese partners, a Vietnam IPv4 is not a nice-to-have, it is a requirement. A dedicated IPv4 in the Vietnam range means your n8n webhooks, GitLab webhooks, and mail relays present a local address. That matters for three reasons.

First, domestic routing. Traffic between a Vietnam IP and Vietnamese users stays on domestic links, which keeps latency low and avoids congested international trunks. Second, mail deliverability. A Vietnam IP with correct rDNS and SPF records lands in Vietnamese inboxes far more reliably than an offshore IP with a clean but foreign reputation. Third, compliance. Vietnamese regulations increasingly push companies handling local data to keep it inside the country. A VPS with a Vietnam IPv4 in a Tier 3 datacenter, like the ones thueVPS operates in Viettel IDC and VNPT IDC, addresses that cleanly.

The trade-off is international bandwidth. A Vietnam VPS is local infrastructure for work that touches Vietnam; anything leaving the country crosses international transit. If most of your clients are in the US or Europe, an offshore VPS may serve them better. But for an IT services company with Vietnamese clients, the local IPv4 wins every time.

Troubleshooting common failures

The VPS runs out of memory and the n8n container dies. Check what happened before you resize:

journalctl -u docker --since "1 hour ago" | grep -i oom

If you see OOM kills, the fix is not always more RAM. Look at the workflow that was running, add swap, or split heavy workflows across time using cron instead of running them concurrently.

Webhooks from client systems time out. This is almost always the firewall or the reverse proxy, not the VPS. Verify the port is listening:

ss -tlnp | grep :443

If nothing shows, the reverse proxy is not running. Check systemctl status nginx and look at nginx -t for config errors before restarting.

Email from the relay lands in spam. Run the standard DNS checks first:

dig +short TXT _dmarc.yourdomain.com
dig +short TXT yourdomain.com | grep spf
dig +short PTR 203.0.113.10

Fix the missing records one by one. A clean IP with correct SPF, DKIM, DMARC, and rDNS is the entire game for deliverability.

FAQ

Related articles

• Self-hosting n8n for workflow automation on a VPS
• Self-host GitLab CE on a VPS in 2026, step by step
• Self-host VPS monitoring with Prometheus and Grafana
• Configure SPF, DKIM and DMARC on a mail VPS