From 2fb2a2980d7c61562c59cac69c9da5c30b218612 Mon Sep 17 00:00:00 2001 From: Claude Date: Mon, 10 Aug 2026 00:09:49 +0000 Subject: [PATCH 1/2] Document the 6vCPU/8GB Tier 3 sizing plan MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Settled stack: 3x Mattermost, 1x Traccar (down from 2x to buy back RAM), 2x each of ntfy/mealie/wordpress/actualbudget/audiobookshelf/emby (music-only + everything)/filebrowser/fmd/homebox/joplin/rustdesk/ vaultwarden, 1x each of asterisk/security-dashboard/sms-inbound (all three are singleton-by-design, no multi-instance support exists for them). changedetection and magicmirror x6 dropped — the former never got the full multi-instance retrofit, the latter's existing pattern caps at 3 instances. Comes out to ~6.0GB of 8GB (~25% headroom) with RustDesk's relay for screen sharing, or ~6.4GB (~20% headroom) with MeshCentral instead. --- docs/vps-sizing-recommendations.md | 112 +++++++++++++++++++++++++++++ 1 file changed, 112 insertions(+) diff --git a/docs/vps-sizing-recommendations.md b/docs/vps-sizing-recommendations.md index cb2a1fe..2dfc01b 100644 --- a/docs/vps-sizing-recommendations.md +++ b/docs/vps-sizing-recommendations.md @@ -210,3 +210,115 @@ uncertainty, and they're stacked close enough to the ceiling that it's worth confirming. If real usage runs higher than estimated, the two Mattermost instances (~1.2GB combined) are the single biggest lever to reconsider. + +## Tier 3 — 6 vCores / 8GB RAM / 240GB NVMe + +Example: IONOS VPS L+, $21/mo. + +## What I was planning for the 6vCPU / 8GB / 240GB box + +A much larger multi-instance spread than the Tier 2 box, sized against this +repo's multi-instance retrofit (`services/*.sh` instance-selection pattern, +see `CLAUDE.md`'s "Multi-instance services" section) plus its port-collision +scanning (`CLAUDE.md`'s "Port collision avoidance" section). The instance +counts below aren't arbitrary — a few of them ran into real limits in the +codebase as it exists today, not just RAM ceilings. + +**Not actually possible as "2x" — singleton-by-design, no multi-instance +support exists:** +- `asterisk` — one PBX per box. Fixed SIP port 5060, one AMI, one + DigitalOcean-layout detection, one extension plan. A second instance + would fight the first over the same SIP/RTP ports; there's no + instance-suffix logic to make that not collide. +- `security-dashboard` — runs natively (not Docker), reads *one* Asterisk's + security log and talks to *one* CrowdSec via `cscli`. There's no second + log/CrowdSec on the box to point a second copy at. +- `sms-inbound` — also native, tied to one Asterisk + one pstn-trunk's + DID-ownership mapping. Same story as security-dashboard. + +All three stay at **1x** on this box regardless of how the rest of the +stack is sized. + +**Dropped from this plan, not attempted:** +- `changedetection` × 2 — only got the port-collision-scanning pass this + session, not the full multi-instance retrofit (no directory-suffix + logic), so a second install would collide with the first's + `~/docker/changedetection`. It also runs a dedicated Playwright/Chrome + sidecar per instance (~300-500MB each) — expensive for what would be a + head-to-head with retrofitting it. +- `magicmirror` × 6 — its existing multi-instance pattern (a different, + earlier design than the rest of the repo: upfront instance count, not + incremental) is hardcoded to 1-3 instances. Six would need a code change, + not just a bigger box, and 6 dashboard instances (~900MB) was a lot of + RAM for the value versus the rest of this stack. + +**Screen-sharing tool — RustDesk over MeshCentral.** Both `services/rustdesk.sh` +and `services/meshcentral.sh` have real multi-instance support. RustDesk's +relay (`hbbs`/`hbbr`) is a lightweight Rust binary that doesn't decode video +itself — screen-share traffic goes peer-to-peer between clients, the relay +just proxies — so it costs ~40MB per instance versus MeshCentral's full +Node.js app per instance (~150-250MB). Chose RustDesk for the RAM headroom; +MeshCentral remains the pick if agent-based remote management (not just +screen viewing) matters more than the RAM difference. + +**Everything else scales the same way it does on the Tier 2 box** — same +shared `coturn`, same NetBird base install, same dedicated-per-instance +database pattern (Traccar's own datastore, Joplin/WordPress's dedicated +Postgres/MariaDB per instance, per CLAUDE.md's backup-isolation reasoning). +`traccar` settled at **1x** (not 2x) specifically to buy back RAM — JVM +apps don't shrink well when duplicated (~425MB is mostly fixed heap +overhead, not data-proportional), so a second instance was the highest-RAM, +lowest-value item once Mattermost stayed at 3x. + +**Emby** stays music-only-plus-everything (2 instances, one restricted to a +Music library per CLAUDE.md's per-user-access pattern, one unrestricted) — +idle RAM only; if the "everything" instance serves remote clients that +can't direct-play, transcoding adds real CPU plus ~200-400MB per active +session, not counted in the idle table below. + +**No automatic swapfile on this box.** `ensure_swapfile()` only offers one +when RAM ≤4096MB — an 8GB box doesn't qualify, so unlike every Tier 1/2 box +in this doc, this one has no swap unless it's added by hand. + +## Final RAM budget for the 6vCPU/8GB box (settled baseline, idle) + +| Service | Count | ~RAM | +|---|---|---| +| OS + Docker baseline (~45-50 containers across all instances) | — | ~500MB | +| Caddy | — | ~30MB | +| CrowdSec | — | ~150MB | +| coturn (shared) | — | ~40MB | +| NetBird client | — | ~35MB | +| Asterisk | 1 (singleton) | ~100MB | +| security-dashboard + sms-inbound | 1 each (singleton) | ~95MB | +| Mattermost (app+Postgres each) | 3 | ~1800MB | +| Traccar (JVM) | 1 | ~425MB | +| ntfy | 2 | ~100MB | +| Mealie | 2 | ~350MB | +| WordPress (dedicated MariaDB/site) | 2 sites | ~400MB | +| Actual Budget | 2 | ~140MB | +| Audiobookshelf | 2 | ~400MB | +| Emby (music-only + everything) | 2 | ~450MB idle* | +| Filebrowser | 2 | ~80MB | +| FMD | 2 | ~100MB | +| Homebox | 2 | ~250MB | +| Joplin (app + dedicated Postgres each) | 2 | ~400MB | +| RustDesk relay | 2 | ~80MB | +| Vaultwarden | 2 | ~80MB | +| **Total** | | **~6.0GB** | + +\* idle only — see the Emby note above for active-transcode cost, not +included here. + +Leaves roughly **~2.0GB headroom (~25%)** out of 8GB — right at the bottom +of the ideal 25-30% range from the sizing rules of thumb above. Swapping +`rustdesk` for `meshcentral` narrows that to ~1.6GB (~20%) — still +workable, just tighter. CPU isn't expected to bind here (no +transcoding/AI/gaming load in this mix per the "How to size" rule of +thumb above), but 3 concurrent Mattermost calls, active Asterisk calls, +and a RustDesk/MeshCentral session all at once is the realistic worst +case worth watching, not the idle numbers in this table. Deploy +incrementally and check `free -h` / `docker stats` against this table the +same way as the Tier 2 box — if real usage runs higher than estimated, +Mattermost (~1.8GB across 3 instances) is again the single biggest lever +to reconsider. From 666d280179739c4361ec6a994df666f332fff18e Mon Sep 17 00:00:00 2001 From: Claude Date: Mon, 10 Aug 2026 00:15:33 +0000 Subject: [PATCH 2/2] Document IONOS Object Storage pricing Storage cost matches what was already known from IONOS chat support (~$0.49/100GB/month). Found the two unknowns from IONOS's own published price list rather than pricing-comparison sites, which had conflicting numbers for the API-cost line: API requests (PUT/COPY/POST/LIST/GET/ DELETE) are free with no per-request charge, and outbound transfer is free up to 2TB/month (shared across the whole IONOS contract, not scoped to Object Storage alone) before tiered per-GB rates kick in. Relevant to services/immich.sh's S3 storage engine. --- docs/vps-sizing-recommendations.md | 37 ++++++++++++++++++++++++++++++ 1 file changed, 37 insertions(+) diff --git a/docs/vps-sizing-recommendations.md b/docs/vps-sizing-recommendations.md index 2dfc01b..d0c130b 100644 --- a/docs/vps-sizing-recommendations.md +++ b/docs/vps-sizing-recommendations.md @@ -322,3 +322,40 @@ incrementally and check `free -h` / `docker stats` against this table the same way as the Tier 2 box — if real usage runs higher than estimated, Mattermost (~1.8GB across 3 instances) is again the single biggest lever to reconsider. + +## IONOS Object Storage pricing + +Relevant to `services/immich.sh`'s S3 storage engine (thumbnails, encoded +video, and new uploads offloaded to object storage instead of local VPS +disk — see that file's `IMMICH_STORAGE_ENGINE=s3` support) or any other +service pointed at an S3-compatible bucket instead of a local bind mount. +Storage cost was already known from IONOS chat support (~$0.50/100GB/month +checked out); API and transfer costs were the unknowns — pulled from +IONOS's own published price list (`docs.ionos.com`, IONOS CLOUD Inc. +price list — USD; the EU entity, IONOS SE, may list EUR-denominated rates +that differ slightly) rather than the general pricing-comparison sites, +which had conflicting/stale numbers for the API-cost line. + +| Item | Cost | +|---|---| +| Storage | $0.00487 / GB / 30 days (~$4.99/TB/month, ~$0.49/100GB/month) | +| API requests — PUT / COPY / POST / LIST / GET / DELETE | **Free** — no per-request charge on any operation | +| Inbound transfer (upload to the bucket) | **Free** | +| Outbound transfer (download from the bucket) — up to 2TB/mo | **Free** | +| Outbound transfer — next 8TB (2-10TB/mo) | $0.036 / GB | +| Outbound transfer — next 40TB (10-50TB/mo) | $0.030 / GB | +| Outbound transfer — next 100TB (50-150TB/mo) | $0.024 / GB | +| Outbound transfer — over 150TB/mo | $0.018 / GB | + +**The outbound-transfer tiers are shared across the whole IONOS contract**, +not scoped to Object Storage alone — VPS egress and bucket egress draw from +the same cumulative monthly pool. For a personal Immich-style workload +(thumbnail/originals fetched by a handful of client devices, not a public +CDN), 2TB/month of combined egress is a lot of headroom — this is +effectively storage-cost-only in practice (~$0.49/100GB/month), with API +calls and typical download volume both landing in the free tier. + +Sources: +- [IONOS Cloud Inc. price list](https://docs.ionos.com/cloud/support/general-information/price-list/ionos-cloud-inc) +- [IONOS Object Storage — pricing model overview](https://docs.ionos.com/cloud/backup-and-storage/ionos-object-storage/overview/pricing) +- [IONOS Object Storage product page](https://cloud.ionos.com/storage/object-storage)