Turbo: the Compose-stack server

Why four cores changes things

At four vCPUs you stop thinking about which process gets the CPU. A web tier, a worker pool, a database and a cache can all be busy at the same moment without queueing behind each other. That is why Turbo is where most multi-service stacks land: it is the first size where concurrency is no longer a design constraint.

It also makes the box usable while it works. You can run a migration, rebuild an image and tail logs over SSH without the shell becoming sluggish.

A worked Compose stack

A realistic stack for a small product, with memory limits that add up to something Turbo can hold with room for page cache:

services:
  proxy:
    image: caddy:2
    ports: ["80:80", "443:443"]
    deploy: { resources: { limits: { memory: 128m } } }
  web:
    image: registry.example.com/app:latest
    deploy: { replicas: 2, resources: { limits: { memory: 768m } } }
  worker:
    image: registry.example.com/app:latest
    command: ["worker"]
    deploy: { resources: { limits: { memory: 768m } } }
  db:
    image: postgres:16
    shm_size: 256m
    deploy: { resources: { limits: { memory: 2560m } } }
  redis:
    image: redis:7
    command: ["redis-server", "--maxmemory", "256mb"]
    deploy: { resources: { limits: { memory: 320m } } }

Limits total roughly 5.3 GB. The OS and Docker daemon take about half a gigabyte. That leaves around 2 GB for the kernel's page cache, which the database will happily use. For a longer walkthrough, including volumes and rolling restarts, see Docker hosts.

Staging that behaves like production

The other big job for Turbo is staging. A staging environment is only worth having if it fails the same way production does, and that means similar core counts, similar memory pressure and the same disk class. Turbo is close enough to most small production fleets that load tests and migrations tell you something true. The staging environments write-up covers seeding data and keeping secrets out of it.

Disk: 80 GB and Docker

Docker is the usual reason an 80 GB disk fills. Every build leaves layers, and every pulled tag stays until you prune it. Two habits keep it under control:

# see where the space went
docker system df -v | head -40

# keep build cache to a sensible size
cat > /etc/docker/daemon.json <<'EOF'
{ "log-driver": "local", "log-opts": { "max-size": "20m", "max-file": "3" },
  "builder": { "gc": { "enabled": true, "defaultKeepStorage": "10GB" } } }
EOF
systemctl restart docker

The local log driver with rotation stops a chatty container writing gigabytes of JSON logs, which is the second most common way small disks fill up.

Windows on Turbo

If you need Windows Server 2025, Turbo is the floor we recommend. Four cores and 8 GB give Windows enough room for its own services plus IIS or a .NET app. Talk to support about licensing before you place the order so there are no surprises.

Signs you have outgrown it

• Memory is full but CPU graphs are calm: move sideways to Nitro, which keeps four cores and adds 4 GB.
• All four cores are saturated during builds or peak traffic: Warp adds two cores and doubles memory.
• Everything is quiet and the graphs never move: step down to Boost and save $5 a month.

Plan changes go through support. Open a ticket in the portal, say which size you want, and we will schedule it.

Price

Turbo is $13 monthly or $130 annually. We bill in US dollars, so if you pay with a sterling card the amount on your statement will move slightly with the exchange rate. No setup fee, and the same 1 Gbps unmetered port and dedicated IPv4 as every plan.