Known limitations

Know what The Gateway does not solve.

The Gateway is released, but limitations stay visible so operators can separate proven behavior from unsupported assumptions and privacy boundaries.

Deployment scope

Hardware support depends on real reports and the current hardware matrix.
Each install still needs route, DNS, fallback, recovery, and backup checks.

Service scope

Appliance, MSP, and managed operations paths require repeatable deployment evidence per environment.
Support is bounded by explicit operator approvals and redacted diagnostics.

Privacy boundary

The Gateway can help verify privacy posture but does not guarantee anonymity by itself.
Browser fingerprints, logged-in accounts, payments, and endpoint compromise remain outside the gateway boundary.

Limitation evidence

Each limitation stays visible until matching evidence narrows it.

Redacted Gateway dashboard showing route, DNS, tunnel, device, and backup status cards — Deployment scope **Needs reproducible state.**
Shows the posture summary that should be linked to install notes and remaining risks.

Redacted Gateway devices inventory screen — Hardware scope **Needs hardware reports.**
Shows device scope that should be backed by reports before support claims expand.

Redacted Gateway DNS control screen — Privacy boundary **Needs observable checks.**
Shows DNS behavior as evidence for posture verification, not as an anonymity guarantee.

Next action

Use install readiness to make the limits explicit.

Start with the install readiness checklist, then review support boundaries and attach install notes, route and DNS checks, fallback checks, recovery drills, hardware reports, and privacy posture checks to clarify remaining limitations.

Open readiness checklist Review support boundaries Open evidence checklist Open product status Open installation guide