A small server can be useful long before it is powerful. The more important question is how much room your current workload leaves for the next thing.
On November 1, 2026, we inspected a shared Linux VPS already running several web, collection and database services. This is a report of that snapshot. It is not a promise that every 4 GB VPS can run the same mix.
The sample, with its boundaries
| Measure | Observed |
|---|---|
| Logical CPUs | 2 |
| Total memory | 3,910 MiB |
| Available memory | 1,423 MiB |
| Swap total / free | 2,400 / 1,381 MiB |
| Free space on the root filesystem | 25.4 GiB |
| Sampling time | 2026-11-01, 14:33 UTC |
The snapshot used the system memory report, a filesystem space query and one docker stats --no-stream sample. No load generator was running as part of this check. We did not measure sustained peak consumption, request latency under load or recovery after an out-of-memory event.
Download the reduced, public snapshot (JSON). It contains the aggregate measurements above, without access credentials or private service configuration.
A configured limit is not current usage
In the same sample, one worker used about 244 MiB against a 256 MiB container memory limit. That is close to its configured ceiling at that moment. It does not prove an ongoing failure, and it does not justify increasing every container limit.
A limit is a control on what a service may consume. A measurement describes what it did consume under specific conditions. Adding limits is useful when considering possible exposure; adding a single sample of usage is useful for understanding the present. Neither number alone is a peak-capacity test.
Make the next service earn its memory budget
- Record available memory while the existing services perform their ordinary work.
- Sample the new service separately: idle, a typical task, and a task large enough to reveal its working set.
- Leave room for the operating system, existing jobs and overlapping work. Treat an allowance as your choice, not a universal constant.
- Repeat the measurement after scheduling the new task. Check latency, errors and memory pressure together.
Our free VPS memory budget calculator performs the subtraction and exports a small CSV. Its sample values are editable examples. It cannot infer demand from a software name or replace measurements on your host.
Swap needs context
Some swap was occupied. A single snapshot cannot tell us whether that reflects old, inactive pages or sustained memory pressure. The useful follow-up is to look at swap activity and pressure over time, during actual jobs, alongside service behavior.
For this publication, static HTML and browser-side tools are a deliberate first choice. They can be served by the existing web server, without adding another database or a long-running application process. We have not benchmarked the site's maximum traffic capacity.
Sources and reproducibility
- Docker: container statistics and memory accounting
- Linux kernel documentation: proc filesystem and memory fields
- Our reduced snapshot
Limit: one host, one short sample, existing mixed workloads. These observations do not establish a safe application count, a benchmark ranking or production acceptance for another machine.