# The Gateway Install Readiness

This page is the public pre-launch install target until the open repository and installer are published.

## What must exist before the install CTA goes live

- Public repository with license, contribution guide, and security model.
- Supported hardware matrix for primary, embedded, portable, and appliance modes.
- Install guide for a clean Linux gateway.
- Safe-mode recovery notes for DNS, routing, firewall, and admin lockout.
- First-run wizard or CLI path for interface selection, DNS policy, and first route profile.
- Validation checklist for DNS forcing, route ownership, DNS ownership, fallback state, privacy posture, and leak checks.
- Upgrade and rollback notes.
- Redacted support bundle format.

## First install path

1. Choose deployment mode: primary gateway, embedded gateway, or portable gateway.
2. Map interfaces and confirm out-of-band admin access.
3. Bootstrap the gateway daemon and local UI.
4. Create a default device group and DNS policy.
5. Preview route ownership and fallback behavior.
6. Apply the first policy.
7. Run validation: connectivity, DNS trace, route trace, fallback state, and leak checks.
8. Save a known-good backup and rollback note.

## Before requesting review

- Name the current route owner, DNS owner, fallback owner, and final apply approver.
- State whether the review is advisory only or preparing for a bounded live install window.
- Document the current route, DNS, fallback, and policy state before the first install attempt.
- Confirm console, SSH, or local recovery access before changing DNS, routes, firewall state, or remote access.
- Keep a known-good rollback target or timestamp for policy, resolver, and transport state.
- Describe the intended privacy posture and what evidence will verify it after install.
- If screenshots are part of the evidence package, capture them read-only, redact real values into realistic synthetic values, note the surface reviewed, the screenshot decision/result, and whether the current assets stayed sufficient.
- If the evidence package is docs-only or copy-only, screenshots may stay unchanged, but the review notes must still name the surface reviewed, the screenshot decision/result, and explain why the current assets were sufficient.
- Keep visitor-facing install, evidence, and release copy free of internal development terms, tooling names, workspace paths, versioned deployment URLs, and provider-specific deployment endpoints.
- Keep build output free of workspace metadata, hidden workspace directories, dependency directories, and repository internals such as `AGENTS.md`, `SOUL.md`, `USER.md`, `node_modules`, and `.git`.
- Review support/export boundaries before sharing diagnostics or granting remote access.

## Launch blocker

The install CTA should point to the public repository install guide only after the installer, recovery path, and hardware matrix have been verified on a fresh machine.

Use the [launch status](./launch-status.html) page for the public summary of what is reviewable now, what is still gated, and what proof is still missing.

After the install review, use the [rollback and recovery](./rollback-recovery.html) guide before moving to the production checklist.

When the review confirms fresh-machine install evidence, move to the [production checklist](./production-checklist.html) before treating the site as launch-ready.