Why these six
A FastNode server is a VMware virtual machine in London. It has dedicated vCPUs from your plan, NVMe-backed storage, a 1 Gbps port with unmetered traffic and one IPv4 address. You get root from first boot. That combination suits workloads that are disk-sensitive, latency-sensitive for UK users, or awkward to run on platforms that hide the operating system. The six below are where we see that fit most clearly.
CI runners
Hosted CI minutes get expensive once a team pushes all day. A self-hosted runner on a fixed monthly price turns that into a known cost. It also keeps dependency caches warm between jobs, so builds stop re-downloading the same packages. NVMe storage cuts the time spent unpacking caches and writing build artefacts. The page covers GitHub Actions, GitLab and Forgejo runners, ephemeral versus persistent runners, and why build hosts suit Warp and Hyper.
API backends
If your users are in the UK, a backend in London cuts round-trip time for every request. A plain VM gives you control over the reverse proxy, TLS settings, connection limits and process supervision. The guide walks through a production layout: Caddy or nginx in front, the app under systemd, health checks, and zero-downtime restarts. It also covers how far a Boost plan really goes.
Docker hosts
Plenty of teams don't need an orchestrator. One well-run Docker host with Compose, a reverse proxy and sensible logging can serve a product for years. A full VM gives you a real kernel, so Docker, Podman and their networking work as documented, with none of the restrictions of container-based VPS platforms. The page covers storage drivers on NVMe, log rotation, image pruning and keeping Docker's port publishing from bypassing your firewall.
Databases
PostgreSQL, MySQL, MariaDB and Redis all reward fast random I/O and plenty of RAM for cache. The Nitro plan exists for exactly this: 12 GB of memory on four cores. You can give a database a large buffer pool without paying for cores it won't use. The guide covers memory settings, WAL and fsync behaviour, backups that actually restore, and keeping the database port off the public internet.
Staging environments
A staging server is only useful if it behaves like production. Deploy the same image and the same plan shape, and run the same deploy pipeline. Because every plan comes with the same seven images, you can match production's OS release exactly. Snapshots make it cheap to reset staging to a known state before each test run. The page covers configuration parity, seeded data, access control and tearing environments down.
Self-hosted Git
Forgejo, Gitea and GitLab CE let you keep source code, issues and packages on a server you control, inside the UK. Forgejo and Gitea run comfortably on a Boost. GitLab CE needs far more memory and belongs on Nitro or above. The guide covers SSH on a non-conflicting port, backups of repositories and the database together, and wiring a runner on a second server.
Choosing a plan across workloads
| Workload | Start on | Move up when |
|---|---|---|
| Single API service | Spark | p95 latency rises under load, or you add a local database |
| API plus database | Boost | database cache hit ratio drops below about 99% |
| Docker host, several stacks | Turbo | memory pressure or disk fills with images |
| Primary database | Nitro | working set outgrows RAM |
| CI build host | Warp | jobs queue behind each other |
| Heavy parallel builds | Hyper | you need a second runner, not a bigger one |
Prices and full specifications are on the pricing page. Plans bill monthly or annually, and annual billing costs ten months' worth. To move between plans, ask support. We'll tell you what's involved for your server. Start smaller than you think you need, measure real load for a fortnight, then decide.