Minimum Requirements to Deploy Anywhere — The Deliberate "8 vCPU, 16 GB, One VM" Decision

CollabOps's minimum system requirements in one line:

1 VM + 8 vCPU + 16 GB RAM + 200 GB SSD + 1 internal IP + sudo.

That single line is half of how we describe the product. Producing it took six months and four architectural decisions. This post is those four.

Compared — why are we the only ones with this line?

Tool                       | Minimum
───────────────────────────┼────────────────────────────────────────────────
GitLab self-managed        | 4 vCPU + 4 GB (5 users); 50+ → k8s recommended
Atlassian Data Center      | k8s cluster + external PostgreSQL + LB + shared FS
GitHub Enterprise (GHES)   | VMware/AWS only, 4 vCPU min, no k8s support
Jenkins (LTS)              | Java 11+, 256 MB min, ops separate
GitLab self-managed (50+)  | k8s + external DB + Redis + S3-compatible storage
CollabOps                  | 1 VM + 8 vCPU + 16 GB + 200 GB + sudo

GitLab looks lighter at 5 users. Past 50 it recommends k8s. CollabOps stays on the same one VM up to 50 users. Up to ~200 on the same VM with stepping (16 vCPU instead of 8).

Decision 1 — embedded lightweight k8s, transparent externally

The single-VM CollabOps deploy embeds a lightweight k8s distribution internally. Invisible to the user. The user never even hears the word k8s. Only one systemd unit runs.

Why:

• k8s operational model available without requiring user knowledge
• Same deploy artifact as Class 2 (existing k8s) — Helm chart works for both
• Future Class 1 → Class 2 migration, five years out, possible without reinstall

Alternative — static binary + supervisord. Simpler, but cuts off the migration path. We chose future option over present simplicity.

Decision 2 — Postgres embedded vs external — embedded as default

Postgres runs inside the same VM. External DB is an option, but the default is embedded.

• Backup: VM snapshot or automatic pg_dump cron
• HA: none (Class 1 by definition)
• Data migration: pg_dump → pg_restore on new VM

Alternative — require external DB from day one. More robust, but doubles the customer's barrier to entry from one VM to one VM + a DB server. Double the barrier and a large share of Class 1 (one departmental VM) never even starts evaluating. Decision: embedded.

Decision 3 — bake observability in

Prometheus / Grafana / Loki — the o11y stack — runs inside the same VM. Customers get monitoring out of the box, no extra infrastructure.

Cost — memory +2 GB. We raised the minimum from 14 → 16 GB. The barrier those 2 GB add is near zero — most VM default profiles are already 16 GB.

Alternative — make o11y an external dependency. Integrate with the customer's existing Prometheus. We offer this as an option but not as default.

Decision 4 — bootstrap automation — from first command to first login

One installer downloads + runs on the VM. 4 hours later, first login is ready.

$ curl -sSL https://onprem.collabops.ai/install.sh | sudo bash
[OK] Validated VM (8 vCPU, 16 GB RAM, 200 GB SSD)
[OK] Internal IP detected: 10.0.45.12
[INFO] Installing embedded kubernetes...
[INFO] Pulling images (offline tarball if available)...
[INFO] Bootstrapping Postgres...
[INFO] Bootstrapping CollabOps services...
[INFO] Configuring observability...
[OK] Done. First login: https://10.0.45.12:8443/  (admin / <one-time token>)

4 hours of human effort — one command, one first login. Everything else is waiting.

This automation cost us — 12 months of work, 3 SREs of time. In return, a one-hour first PoC meeting can now walk through the entire installation as a live demo.

What the four decisions share

• No assumption of customer infrastructure expertise
• No infringement on customer's existing infrastructure
• No blocking of the customer's next decision

That triplet is the real meaning of the one-line minimum.

Why other tools can't do this

GitLab and Atlassian have larger minimums because they were designed cloud-first for large teams. We started from a different set of assumptions, and that assumption gap produces today's deploy artifact gap.

Cloud-first systems retrofitting self-hosted end up with large minimum requirements. → Why we default to self-hosted

Should you be suspicious of large minimum requirements?

Yes — if a self-hosted DevOps tool's minimum requirement is much larger than one VM + 8 vCPU, that suspicion is correct. Large minimums often reflect the vendor's architectural assumptions more than the customer's environment. If you're the IT decision-maker evaluating self-hosted tooling right now, check whether reasoning like the four decisions above sits behind the spec line.