$8/mo USDor $80/yr
Deploy Boost in London- vcpu
- 2
- memory
- 4 GB
- nvme disk
- 40 GB
- port
- 1 Gbps
- traffic
- unmetered
- ipv4
- 1 dedicated
The shape of a Boost workload
The typical Boost server runs three things: a reverse proxy terminating TLS, an application process, and a database. Maybe a Redis for sessions. That is a complete production stack for a SaaS in its first year, an internal tool for a team of twenty, or an API serving a mobile app with a few thousand daily users.
Two vCPUs is the important upgrade over Spark. With two cores, the database can work on a query while the app serializes a response, and a background job no longer makes every request wait. Latency stays flat under the kind of mixed load real apps generate.
Dividing four gigabytes
A working memory plan for app plus Postgres on one box:
| Slice | Allocation | Notes |
|---|---|---|
| OS and system services | 300 MB | Debian or Ubuntu minimal |
| Postgres shared_buffers | 1 GB | about 25% of RAM |
| Postgres connections and work_mem | 300–500 MB | keep max_connections low; pool in the app |
| Application | 600 MB–1 GB | cap it with systemd MemoryMax |
| Redis (optional) | 128–256 MB | set maxmemory explicitly |
| Page cache | remainder | Postgres relies on it |
The line that people skip is the cap on the application. Without it, one leaking worker can push Postgres into swap and every query slows down at once.
# /etc/systemd/system/app.service.d/limits.conf
[Service]
MemoryMax=1G
MemoryHigh=900MInstalling the database
On Ubuntu 24.04 or Debian 12, the distribution Postgres is perfectly good. Tune the three settings that matter at this size and leave the rest alone:
apt -y install postgresql
cat >> /etc/postgresql/*/main/conf.d/small.conf <<'EOF'
shared_buffers = 1GB
effective_cache_size = 2560MB
max_connections = 40
random_page_cost = 1.1
EOF
systemctl restart postgresqlrandom_page_cost = 1.1 tells the planner that random reads are almost as cheap as sequential ones, which is true on NVMe-backed storage and nudges it towards index scans. More on that in the databases use case.
40 GB, and what to do with it
Forty gigabytes holds the OS, your code, a few years of logs if you rotate them, and a database in the low tens of gigabytes. What it should not hold is your only backup. Dumps on the same disk as the data protect you from a bad migration, not from losing the server. Ship them elsewhere; the backups and snapshots guide walks through a nightly pg_dump pushed off-box alongside portal snapshots.
Watching for the ceiling
Boost runs out in one of three ways, and each points to a different next step:
- Memory: page cache shrinks to almost nothing and Postgres reads start hitting disk. Go to Turbo for 8 GB.
- CPU: both cores sit above 70% at peak in the portal graphs. Turbo doubles cores to four.
- Isolation: you want the database to survive an app deploy gone wrong. Keep this Boost for the database and add a Spark for the app.
Check memory pressure directly rather than guessing:
cat /proc/pressure/memory
vmstat 5 5Non-zero full values in the PSI output mean tasks are stalling on memory. That is the clearest signal you have outgrown the box.
Price
Boost is $8 a month, or $80 if you pay for the year up front. Those figures are in US dollars, which is how checkout bills; there is no setup fee. It includes the same 1 Gbps unmetered port and dedicated IPv4 as every other plan.