Before this:Deploying to the cloud & VPS
Cost & resource management
Key takeaways Every deployment costs money and consumes finite CPU and memory. Right-sizing means matching what you allocate to what the workload actually uses — measure first, then set limits a margin above the real peak. Over-provisioning wastes money; under-provisioning causes throttling and crashes. Cloud pricing models (on-demand, reserved, spot) trade commitment for discount. Limits also protect the host: one greedy container can’t starve the rest.
You’ve deployed to a cloud or VPS — which sends a bill and hands you a fixed pool of CPU and memory. This lesson keeps that bill sane and that pool from being exhausted, without starving the service into instability. It’s the practical end of operating: affordable and stable.
Measure before you size
You can’t right-size what you haven’t measured. Watch real usage over a representative period — a busy day, not an idle minute — using the metrics you already collect and basic host tools:
docker stats gophertrunk # live CPU / memory for the container
free -h # host memory headroom
The number that matters is the sustained peak under real load, plus a margin. Size to that, not to the average (you’ll throttle at peak) and not to the worst case imaginable (you’ll pay for headroom you never touch).
Set requests and limits
Once you know the real usage, cap it. In Compose:
services:
gophertrunk:
deploy:
resources:
limits:
cpus: "1.0" # never use more than 1 core
memory: 512M # killed & restarted if it exceeds this
reservations:
memory: 256M # guaranteed this much
GopherTrunk’s shipped systemd unit offers the
same as commented defaults — MemoryMax=1G, TasksMax=256 — described as conservative
for a 2-SDR setup. Limits do double duty: they keep cost predictable and they protect
the host, since a limited container can’t consume the whole machine and take its neighbours
down with it.
Over- and under-provisioning
Right-sizing lives between two failure modes:
- Under-provisioning — too little CPU throttles the service and too little memory gets it killed. Cheap on paper, expensive in outages.
- Over-provisioning — a giant instance running at 5% utilisation. Stable, but you’re paying for idle capacity every hour. It’s the more common and quieter waste.
Cloud pricing models
Cloud providers price the same capacity differently depending on how much you commit:
| Model | You pay | Trade-off |
|---|---|---|
| On-demand | Full rate, no commitment | Flexible; most expensive per hour |
| Reserved / committed | Discount for a 1–3 year commitment | Cheaper for steady, predictable load |
| Spot / preemptible | Deep discount, can be reclaimed anytime | Cheapest; only for interruptible work |
A steady service like a always-on GopherTrunk instance suits reserved pricing or a flat-rate VPS; bursty batch jobs that can tolerate interruption suit spot. Match the pricing model to the workload’s shape and the same compute costs far less.
Keep it honest over time
Costs drift: a service grows, an instance was sized for a spike that’s long gone, a forgotten test box bills forever. Revisit sizing periodically against fresh metrics, delete what you don’t use, and set a billing alert so a surprise bill pages you like any other symptom. Cost is just another signal to observe and keep in bounds.
Quick check: what is right-sizing?
Recap
- Measure real usage (sustained peak) before sizing anything.
- Set limits and reservations to cap cost and protect the host from a greedy container — GopherTrunk’s unit ships conservative defaults.
- Under-provisioning throttles and crashes; over-provisioning wastes spend — right-sizing sits between.
- Match the pricing model (on-demand, reserved, spot) to the workload’s shape.
- Revisit sizing over time and alert on the bill like any other signal.
Next up: putting it all together — deploying GopherTrunk end to end.
Frequently asked questions
What does right-sizing mean?
Right-sizing means matching the CPU and memory you allocate to what the workload actually uses — not far more (wasted money) and not far less (throttling and crashes). You measure real usage over time, then set requests and limits a sensible margin above the observed peak. It’s the core discipline of keeping a deployment both affordable and stable.
Why set CPU and memory limits on a container?
Limits cap how much a container can consume so one misbehaving service can’t starve everything else on the host. A memory limit also makes failures predictable — a leaking container is killed and restarted instead of taking the whole machine down. Without limits, a single runaway process can bring down every other service sharing the box.