All products 
VPS for development and CI/CD: what matters
Your own server for builds and tests pays off as soon as the free minutes in GitHub Actions or GitLab CI stop being enough. A self-hosted runner has no time limits and keeps dependency and Docker image caches, which makes repeat builds several times faster. The same VPS also works well as a remote development environment or a staging server.
Cores and memory: builds need a lot, but not for long
Compilation, frontend builds and test runs are parallelised across cores, so for a runner the core count matters more than for a web server. Rough guidelines:
- 2 cores and 4 GB — small Node.js, Python or PHP projects, linters and unit tests;
- 4 cores and 8 GB — building Docker images, Webpack or Vite frontends, integration tests with a database;
- 8 cores and 16 GB — compiling Go, Rust, Java or C++, Android builds, parallel jobs.
If you only run a few builds a day, the server sits idle most of the time. That's where hourly billing helps: you spin up a powerful server for the job and delete it afterwards, paying only for the hours used. Many hosts let you do this through an API, so the runner can be started automatically.
Storage: caches take up more than you'd think
Docker images, npm, pip, Maven or Gradle caches and build artifacts quickly add up to tens of gigabytes. Choose NVMe with 50–80 GB or more and set up cleanup: a scheduled docker system prune and a retention limit for artifacts. Disk speed directly affects how long dependencies take to install — on a slow disk that can take longer than the build itself.
How to connect a runner
- GitHub Actions — a self-hosted runner is installed with a single command from the repository or organisation settings and runs as a service.
- GitLab CI —
gitlab-runnerwith the Docker executor: each job runs in a clean container, and images are cached on the server. - Gitea, Forgejo, Woodpecker, Drone — lightweight alternatives if you also host the repository on your own server; see also VPS for GitLab.
Virtualisation and security
Docker builds need KVM: under container virtualisation Docker often won't start or runs with restrictions (more on the VPS for Docker page). Don't connect a self-hosted runner to public repositories: someone else's pull request could run arbitrary code on your server. Pass secrets through CI variables instead of storing them on disk, and update the runner along with the system.
Where to host it
A server closer to your Git hosting and image registry downloads dependencies faster. For GitHub and Docker Hub, servers in Europe and the US are convenient; from Russia some registries can be hard to reach, so set up mirrors or a pull-through cache in advance.