Hardware Selection¶

Choosing TAPPaaS hardware is a two-axis decision:

1. Axis A — size tier: how big is the platform (who is it for, how much redundancy)?
2. Axis B — capability options: three independent yes/no choices — local AI, local backup, local public IP — each with a well-defined alternative if you answer "no".

This replaces guessing at one monolithic spec: the axes are genuinely orthogonal. An SMB may skip local AI; a home may have no public IP; an evaluator may want neither backup nor ingress.

Axis A — pick a size tier¶

Storage roles (used throughout the install): tanka1 = VMs and critical data, tankb1 = bulk/non-critical data, tankc1 = backup target.

• In a 3-node SMB cluster the classic shape is: Node 1 = foundation, Node 2 = AI/HA (holds the GPU if you choose local AI), Node 3 = backup node (small box, big tankc1).
• Scale-out extends SMB by adding role-dedicated nodes and separating tenants with environments — see the worked multi-tenant example in Add an Environment.
• For large bulk storage, consider ZFS raidz2 on spinning disks with an SSD cache; prefer ECC RAM from SMB tier upward.

Axis B — toggle the capability options¶

Each option is an independent yes/no, layered on any tier. The recurring theme: the satellite is the escape hatch when a capability can't or shouldn't live locally.

The satellite — the gap filler¶

A satellite is a small operator-owned node with a stable public IP — typically a low-cost EU VPS. It is optional and non-invasive (a site with a public IP and local backup needs none) and can carry any combination of three roles:

• reverse-proxy — the answer to no local public IP: blind L4 TLS-passthrough to your local Caddy over WireGuard (your site dials out, so CGNAT is fine; TLS keys stay home).
• backup — the answer to no local backup: an off-site PBS your local PBS is pulled into.
• admin-vpn — public admin reach into the management plane without a public IP.

One satellite can carry all three.

The decision flow — four steps¶

1. Pick a size tier — Evaluation / Home / SMB / Scale-out (Axis A table).
2. Local AI? If yes, add a GPU or unified-memory APU to the node hosting the AI stack (a dedicated AI node at SMB/Scale-out) — size it with the table below.
3. Local backup? If yes, size tankc1 / a backup node. If no, plan a satellite backup role.
4. Local public IP? If yes, standard WAN ingress. If no (CGNAT / dynamic / no-inbound), plan a satellite reverse-proxy (+ admin-vpn).

Sizing local AI — GPU / VRAM guidance¶

Local AI is sized by the memory available to the accelerator and the model size × quantization you want — not by GPU brand. Two hardware paths, both served by the AI stack (vLLM serving → LiteLLM gateway → OpenWebUI):

• Unified-memory APU (the TAPPaaS reference) — an AMD Ryzen AI MAX+ 395 ("Strix Halo") with 128 GB unified LPDDR5x: the iGPU shares system memory, so "VRAM" is a large slice of RAM — which is what lets one inexpensive box reach very large models. Caveats: no FP8 on gfx1151 (use AWQ/GPTQ quantization); ROCm support for this silicon is still maturing.
• Discrete GPU — a dedicated card with its own VRAM (NVIDIA/AMD); size by the table.

Rules of thumb: 4-bit quantization (AWQ/GPTQ) roughly quarters memory use vs FP16 and is the practical choice above ~14B; leave headroom for KV-cache/context on top of the weights. Where a big model matters more than raw speed, the unified-memory APU gives the most capability per euro; where latency matters most, a discrete GPU wins at a given model size.

Reference: what the platform itself needs¶

Budget for the foundation services on top of your workloads:

Network: 2×1 Gbps minimum; 1 Gbps + 2.5 Gbps recommended for production.

Next steps¶

Hardware chosen? Continue with the install:

1. Preparation — network plan, DNS, credentials.
2. Install Foundation — first node, firewall, CICD.