VPS for developers: what to run on your own server

A VPS for developers: a CI runner, your own PaaS, n8n, bots and APIs, Git and monitoring on your own server — the resources and traffic they need.

Cloud services for development are convenient while their free tiers last: CI minutes, automation executions, free instances that fall asleep. Past that point your own server is usually cheaper, because you pay for cores, memory and disk rather than for every build and every run. The price is administration: updates, backups and security are yours. Below is what developers most often run on a VPS, how many resources it takes and how to split services across servers.

What to run on your own server

• CI and builds. Your own GitHub Actions runner or GitLab Runner: NVMe, as much memory as you need, and caches that survive between runs. Guide: Self-hosted GitHub Actions runner on a VPS.
• Deploy on push. Coolify or Dokploy instead of Heroku and Vercel: apps from Git, preview environments, databases and backups. Guide: Coolify on a VPS.
• Automation. n8n with PostgreSQL and webhooks on your own domain, with no execution cap. Guide: n8n self-hosted.
• Bots and APIs. Telegram bots, FastAPI and Node.js services under systemd or in Docker. Guides: Deploy a Telegram bot on a VPS, FastAPI and Node.js with PM2.
• Git for your team. Forgejo or Gitea: repositories, reviews, a package registry and Actions of your own. Guide: Self-hosted Git server.
• Development on the server. VS Code, Cursor or JetBrains over SSH: builds run on the server and your laptop becomes a thin client. Guide: Remote development on a VPS.
• Monitoring. Uptime Kuma watches sites, APIs and certificate expiry and alerts you in Telegram. Guide: Uptime Kuma.
• Databases. PostgreSQL, MySQL and Redis on NVMe. Guides: PostgreSQL, MySQL and MariaDB and Redis.

How many resources you need

Rules of thumb from the guides, with headroom for the OS, Docker and a reverse proxy:

• A bot or a small API — 1 vCPU and 2 GB of RAM, and such a server comfortably hosts several bots.
• n8n — 1 vCPU and 2 GB for a personal instance, 2 vCPU and 4 GB for a working one with the Code node and AI agents, 4 vCPU and 8 GB or more for queue mode with workers.
• Uptime Kuma — 1 vCPU and 1 GB for a couple dozen monitors, 2 vCPU and 2 GB for two hundred.
• Forgejo — 1–2 vCPU and 2 GB together with PostgreSQL for a team of up to five.
• Coolify — from 2 vCPU and 4 GB. The dashboard itself idles at about 300 MB; builds are what eat memory and cores.
• A CI runner — 1–2 vCPU and 2 GB for linters and tests, 2 vCPU and 4 GB for frontend builds, 4 vCPU and 8 GB for Docker images and tests with databases. Each extra parallel runner adds 2 vCPU and 2–4 GB.
• An IDE on the server — 2 vCPU and 4 GB for VS Code or Cursor on a regular project, 4 vCPU and 8 GB for a monorepo. JetBrains officially requires 4 vCPU and 8 GB.

Always add 2–4 GB of swap: builds and language servers produce short memory spikes, and without swap the OOM killer ends them. NVMe noticeably speeds up anything that touches thousands of small files: npm install, builds, project indexing in the IDE.

One server or several

• Everything on one is a fine start. A bot, n8n and a small API get along on 2–4 GB as long as no builds run on the same server.
• Keep builds away from production. Building a large frontend easily takes several gigabytes of memory and every core, and the apps running next to it slow down or crash. Move the runner or build server to its own machine; Coolify supports dedicated build servers for exactly this.
• Keep monitoring away from everything. A server that is down cannot report its own outage, so run Uptime Kuma on another server, ideally in another location.
• Keep experiments off production. A separate small server for trying things out breaks nothing and is easy to reinstall.
• A private network between servers. ForestsNet Cloud support sets up a private network between your servers on request. Apps then reach the database and internal services over it, and those stay off the public internet.

Traffic: what counts

ForestsNet Cloud plans count outbound traffic only; inbound traffic is free. For development this means:

• Free: everything the server downloads — docker pull, apt, npm install, pip install, git clone and git fetch, pushes to your own Git server, webhooks and incoming API requests.
• Counted: everything the server sends out — API and website responses, clones from your Git server, pushes of images to an external registry, backups uploaded to S3.

CI, APIs and test environments usually send little outbound traffic, so the included allowance goes a long way. How the accounting works is explained in Traffic and bandwidth.

Preparing the server

Before installing services:

1. Log in with an SSH key and disable passwords — SSH hardening.
2. Close unused ports with a firewall — ufw firewall. Docker publishes ports around ufw, so bind container services to 127.0.0.1 and expose them through a reverse proxy.
3. Install Docker and Compose — Docker Compose.
4. Add swap and automatic security updates — Server security checklist.
5. Point your domain at the server — an A record, plus AAAA for IPv6 — and get a certificate: Connect a domain and Caddy, which obtains Let's Encrypt certificates on its own.

What to keep in mind on a VPS

• No snapshots. Back up your databases and data yourself and test restores regularly — restic backups, Database backups and Scheduling with cron.
• Nested virtualization is available. You can run your own virtual machines, KVM, Firecracker and the Android emulator inside a VPS. Nested machines are slower than the VPS itself, so for constant load a dedicated server is more comfortable.
• Administration is on you. OS updates, Docker images and the services themselves do not update on their own — set a reminder or enable automatic updates where they are safe.

Plans and use cases for developers are collected on the VPS for developers page.