Back to The Gateway

Support intake

Request guided setup with explicit operator control.

Use guided setup when install, recovery, privacy audit, or policy design needs operator review. Credentials, traffic paths, fallback decisions, and final approvals stay with the operator unless a bounded change window says otherwise.

Deployment
  • Mode: primary, embedded, portable, appliance, or MSP.
  • Hardware, interfaces, upstream router, current DNS source, and current route/default-path state.
  • Admin recovery path, recovery contact, and rollback method available before changes.
Goal
  • Install, upgrade, privacy audit, outage recovery, bridge path, policy design, or MSP handoff.
  • Desired DNS, route, fallback, and privacy posture, plus the current fallback trigger and behavior.
  • Who owns route changes, DNS changes, fallback changes, rollback approval, and final apply approval.
Evidence
  • What redacted bundle can be shared.
  • Whether remote access is allowed for this request.
  • Retention, revocation, change-window expectations, and support boundaries.

Before you send

Confirm the control and recovery boundary.

Ownership
  • Name the current route owner, DNS owner, fallback owner, rollback owner, and final apply approver.
  • State whether this is advisory review or a bounded live change window.
  • Document the current DNS, route, fallback, and policy state before changes start.
Recovery
  • Confirm console, SSH, or local recovery access is working before any route or DNS change.
  • Keep a known-good rollback target or timestamp for policy, resolver, and transport state.
  • Stop the change window if recovery access, rollback proof, or back-out trigger is missing.
Privacy and support scope
  • Describe the intended privacy posture and the evidence available to verify it.
  • Share only the redacted route, DNS, fallback, and failure evidence needed for the request.
  • Review support boundaries before granting remote access or exporting diagnostics.

Cross-check the privacy posture checklist, rollback and recovery guide, and support boundaries before sending a guided setup request.

Support request evidence

Attach screenshots that show scope, proposed change, and rollback readiness.

Redacted Gateway dashboard showing route, DNS, tunnel, device, and backup status cards
Current state Show posture before help.

Gives support enough status context without exposing credentials or raw traffic.

Redacted Gateway routing policies screen
Proposed change Show policy intent.

Clarifies what route, DNS, or fallback surface the request wants reviewed.

Redacted Gateway backup and recovery screen
Back-out Show recovery readiness.

Shows the recovery surface that should exist before any live change window starts.

Next action

Send a guided setup request.

The email template captures current route/DNS/fallback state, rollback ownership, change-window type, recovery access, evidence, access boundaries, and the back-out trigger that stops the session if support should withdraw. If the request starts with a fresh install or recovery review, go to install readiness first. Use the production checklist when the goal is to confirm go/no-go conditions before sending public traffic live.