Known limitations

Pre-launch means some claims still need proof.

The Gateway keeps limitations visible so operators can separate proven behavior from release gates.

Release gates

License selection, fresh-machine install evidence, rollback, hardware matrix, and production contact endpoints.
Self-service install remains gated until evidence is attached.

Product gates

Appliance, MSP, and managed operations paths need repeatable evidence before broad promotion.
Known hardware support starts as untested until reports populate the matrix.

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 proof removes the gate.

Redacted Gateway dashboard showing route, DNS, tunnel, device, and backup status cards — Release gate **Needs reproducible state.**
Shows the posture summary that should be linked before install claims broaden.

Redacted Gateway devices inventory screen — Product gate **Needs hardware reports.**
Shows device scope that should be backed by reports before hardware 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 clear the first release gates.

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

Request install readiness review Review support boundaries Open evidence checklist Open launch status Open production checklist