Trust model, route ownership, DNS ownership, fallback policy, support boundaries, privacy posture limits, and install readiness questions.
Launch status
Pre-launch, useful to review, not yet a broad self-service install.
This page separates what operators can review now from the product gates that still need public evidence, production endpoints, and repeatable recovery proof.
Request an install readiness review with topology, route/DNS owners, fallback expectations, recovery access, and intended privacy posture.
Broad self-service install, hardware support claims, appliance builds, managed operations, MSP workflows, and production conversion endpoints.
Fresh-machine install transcript, route/DNS traces, fallback checks, leak checks, rollback drill, hardware matrix, redacted screenshots with realistic synthetic values, and a note for the operational claim each artifact supports.
Public screenshots should show the actual operator surfaces: dashboard, routing policy, DNS, devices, backup, recovery, and validation views. Private hostnames, account names, addresses, keys, and topology details should be replaced with realistic synthetic examples before publication.
The Gateway does not guarantee anonymity by itself and does not make logged-in accounts, browser fingerprints, payments, endpoint compromise, or malicious relays private.
Public materials should stay focused on operator value, product readiness, limits, and evidence. Internal maintenance notes belong in maintainer docs, not on this status page.
Broad launch should wait until the production domain, support intake, install path, rollback path, security policy, evidence package, and known limitations are all aligned.
Guided help should be advisory or bounded by an explicit change window. Credentials, traffic ownership, recovery, and final approval stay with the operator.
Status by surface
Public copy can be visible before every operational surface is ready.
Homepage, documentation map, launch status, support boundaries, contact privacy, evidence checklist, and readiness intake can be reviewed now. The visitor-facing story should stay focused on the product, proof, and operator boundaries.
The public site uses https://thegateway.pro/ as the single canonical host, and public host routing should keep visitors on that production surface.
Repository launch should wait for license, security policy, contribution guide, support policy, issue templates, install gates, and release checklist.
Security checks should report no unresolved high-severity issues before broad release.
Support, appliance, managed operations, and MSP paths should wait for real endpoints, redaction rules, owner assignment, and repeatable proof.
Visible proof
The current screenshot set covers the public readiness story.
Shows the operator view behind route ownership, DNS posture, tunnel health, device state, and backup readiness.
Shows how policy attaches to client groups before hardware or appliance support claims broaden.
Shows the backup and restore surface that should support rollback evidence before broad release.