Prepare a local install.
Review routing, DNS behavior, fallback state, recovery access, and privacy posture before the public repository install path opens.
Request install readiness reviewChoose your path
Join the early open-core path, or pay for operational help.
Get operational help.
Guided install, upgrades, recovery review, privacy audit, and policy design. Support uses redacted bundles and explicit export approval.
Request guided setupRepeat the model safely.
Signed builds, managed backups, MSP templates, fleet workflows, and documented support boundaries for repeated deployments.
Join appliance waitlistPre-launch status
Useful now for planning. Conservative before live network changes.
Install shape
Deployment modes, route ownership, DNS ownership, fallback policy, recovery access, and support boundaries are mapped for early operators.
Self-service install
The public install path should stay gated until fresh-machine setup, rollback evidence, and hardware coverage are verified.
Privacy claims
Claims should be tied to route traces, DNS traces, leak checks, fallback behavior, and redacted support evidence.
Readiness review
Start by documenting topology, route and DNS owners, intended privacy posture, and the known-good way back.
Public readiness
The launch page should show what is real, what is gated, and what needs proof.
Route ownership, DNS ownership, fallback policy, support boundaries, and privacy posture limits are visible in public copy.
Domain, public repository, sponsor path, support intake, appliance waitlist, MSP pilot, and evidence intake still need production systems.
Fresh-machine install transcript, rollback drill, hardware matrix, demo screenshots, and redacted support bundle examples remain launch gates.
Hardware, bridge behavior, managed operations, and privacy posture claims should stay scoped until public proof is attached.
What it is
Not a VPN button. A programmable privacy and routing fabric.
Network plane
Interfaces, firewalling, VLANs, WiFi, topology map, and service state sit under one orchestration path.
DNS plane
Filtering, rewrites, per-device policy, telemetry block coverage, and upstream handling are first-class state.
Identity plane
Device groups, trust classes, profiles, personas, exceptions, and secrets separate who you are from where traffic goes.
Path plane
Route profiles, traffic chains, splitting, bridge proxy hops, tunnels, mesh peers, and fallback rules define paths.
Operator outcomes
Built around the moments where ordinary routers go opaque.
Know the active path
See whether traffic is direct, tunneled, split, bridged, blocked, or routed through a peer before it becomes an incident.
Keep privacy enforceable
Turn DNS behavior, leak checks, telemetry blocking, fallback rules, and kill-switch state into visible operating policy.
Recover without guessing
Use validation, drift detection, backups, logs, and rollback-oriented deployment paths when network changes go wrong.
Use cases
Built for operators who need traffic control without black boxes.
Own the default route.
Centralize DHCP, DNS, firewalling, policy routing, mesh access, and observability on a Linux gateway node.
Add policy without replacing the router.
Run embedded mode for selected devices or segments when the upstream router is fixed, ISP-managed, or too risky to change.
Make privacy posture explicit.
Portable mode keeps uplink, DNS, tunnel, fallback, and leak behavior visible instead of relying on implicit VPN assumptions.
Privacy and anonymity
Anonymity is a posture you build, test, and maintain.
Separate devices, roles, and personas.
Use groups, trust classes, profile intent, and policy exceptions so high-risk traffic does not share the same assumptions as ordinary devices.
Stop resolver leaks from deciding for you.
Force intended DNS behavior, detect bypass paths, inspect upstream choices, apply rewrites, and review per-device resolver logs.
Move traffic through the right path.
Use direct routes, tunnels, bridge relays, mesh peers, VPS nodes, and split chains according to the privacy risk of each flow.
Prefer fail-closed operating modes.
Use kill-switch rules, fallback blocks, QUIC/WebRTC controls, telemetry blocking, readiness gates, and post-apply validation where configured.
DNS path, route path, fallback state, tunnel choice, policy decision trace, leak checks, and redacted support evidence.
Logged-in account privacy, payment trails, browser fingerprinting, endpoint compromise, or trust in a malicious remote relay.
The Gateway helps enforce and verify a privacy posture. It does not guarantee anonymity by itself.
Evidence loop
Every risky network change should leave proof behind.
Policy changes are not done until they are verified.
The Gateway is positioned around evidence: before state, intended policy, applied route and DNS behavior, fallback result, leak checks, and a rollback path the operator can actually use.
Operator handoff
Support starts from evidence, not from blind access.
Topology, route owner, DNS owner, fallback owner, active transports, and recovery access.
Which devices, profiles, routes, DNS behavior, and fallback rules should change or stay fixed.
Only the route traces, DNS traces, logs, and screenshots needed for the review.
Change window, stop condition, rollback owner, and final apply approval stay explicit.
Technical and operator detail Open the deeper product model Architecture, runbooks, capability maps, deployment modes, and operational workflows.
Operator recipes
Concrete privacy workflows, not abstract network settings.
One machine, strict posture.
Bind a device to forced DNS, tunnel-only egress, telemetry blocking, WebRTC controls, and fail-closed fallback.
Untrusted Wi-Fi becomes transport.
Run portable mode, force all resolution through the gateway policy, route sensitive flows through a relay, and verify leaks before use.
Different devices, different risk.
Keep normal devices simple while isolating lab boxes, IoT, admin machines, and high-privacy profiles into separate route policies.
Build deliberate remote paths.
Use VPS nodes, bridge relays, peer gateways, and route chains when direct connectivity is not private, stable, or reachable enough.
1
Classify
Choose device group, persona, privacy class, and allowed transports.
2
Preview
Check DNS, route chain, fallback behavior, conflicts, and fail-open risk.
3
Apply
Render policy into firewall, routes, DNS behavior, transport managers, and observers.
4
Verify
Run leak checks, packet capture, drift checks, logs, and rollback readiness.
Who it is for
Operators who need control they can inspect.
Run the gateway where trust starts.
Own routing, DNS, firewalling, policy, and recovery on local hardware instead of treating the router as a closed appliance.
Make outbound behavior explicit.
Verify DNS forcing, leak posture, tunnel fallback, telemetry blocking, and device policy before traffic leaves the network.
Operate remote paths deliberately.
Use bridge nodes, mesh routes, backups, readiness checks, and rollback paths for offices, labs, and constrained environments.
Repeat deployments without chaos.
Package templates, operator runbooks, support snapshots, fleet labels, and handoff docs into a repeatable service model.
Open source model
The privacy layer should be auditable, local, and independent.
Trust starts before traffic leaves.
The Gateway is strongest as an open-source local gateway core: users can verify how routes, DNS, identity separation, fallbacks, bridge paths, and privacy rules behave on hardware they control.
Market position
One control surface for the privacy stack people usually stitch together.
Compared to
The Gateway sits above privacy tools people already know.
Capability matrix
The useful parts are already grouped around operator workflows.
Function catalog
Core functions are grouped by what a privacy operator needs to control.
- Interfaces, DHCP, NAT, firewall, WiFi, VLAN, Bluetooth, services, and platform state.
- Device discovery, topology map, gateway nodes, network health, and service lifecycle.
- DNS resolver, filtering, rewrites, upstream control, per-device behavior, and DNS logs.
- Privacy classes, telemetry blocking, leak checks, QUIC/WebRTC controls, and kill-switch posture.
- Device groups, personas, trust classes, route profiles, exceptions, and scoped secrets.
- Separate ordinary browsing, high-risk devices, lab services, travel nodes, and business clients.
- Routing policies, profiles, chains, splitting, tunnels, proxies, and traffic pipeline state.
- WireGuard, OpenVPN, direct fallback, per-policy hops, and route preview before apply.
- Bridge relay paths, mesh coordination, peer gateways, nodes, roles, and config sync.
- Remote VPS routing nodes and multi-site paths without hiding where traffic goes.
- VPS relays, portable gateways, hostile Wi-Fi mode, split routes, proxy chains, and peer paths.
- Keep ISP, Wi-Fi, office, cloud, and tunnel transports below the policy layer.
- Alerts, anomalies, audit, live logs, packet capture, observers, reconciliation, and drift checks.
- Backup, restore, rollback paths, blue/green deploys, readiness checks, and validation flows.
- Structured automation API, CLI, local policy assistant actions, presets, exceptions, and templates.
- Setup wizard, secrets, device groups, segments, trust classes, and policy lifecycle controls.
Route ownership and policy semantics
The product must explain who owns each decision.
Before apply, the operator sees the path.
A privacy overlay is only trustworthy when the route owner, DNS owner, fallback mode, and blocked reasons are explicit before traffic moves.
Per device, group, segment, interface, and node.
Resolve conflicts when an upstream router, VPN client, DHCP server, or mesh peer also tries to own the default route.
Per-device query trace.
Show device to policy to resolver to upstream to action, including DoH/DoT/DoQ handling, fallback, DNSSEC posture, and sinkhole behavior.
Fail closed, degrade, relay, or quarantine.
Separate WAN, tunnel, DNS, bridge, policy validation, and health-probe failures so degraded state is visible.
Match, action, precedence, approval.
Match by device, group, domain, CIDR, protocol, app, time window, or trust class; then allow, block, route, isolate, capture, or alert.
Enrollment, keys, quality, ownership.
Track gateway, relay, VPS, and peer trust levels, key rotation, NAT traversal, latency, loss, uptime, hosting label, and route authority.
Trace every important decision.
Route decision trace, DNS query trace, policy evaluation trace, blocked leak metrics, fallback events, and redacted support bundles.
Operator Runbooks
Gateway operations become repeatable runbooks.
Turn fragile privacy work into clear procedures.
The Gateway publishes reviewable operator runbooks for install, audit, recovery, bridge setup, privacy posture checks, and MSP handoff. The goal is making high-risk network operations inspectable, repeatable, and easy for an assistant to follow with operator approval.
Open first runbookAssistant-guided runbooks do not replace Gateway docs, operator review, or explicit approval for network-changing actions.
Bring up a local gateway.
Guide hardware checks, network interface mapping, DNS setup, service bootstrap, and first policy apply.
Prove the posture holds.
Run leak checks, DNS forcing validation, identity separation review, tunnel fallback inspection, and report capture.
Fix outages with a known path.
Collect state, compare drift, choose rollback, restore backup, and verify that clients regain safe connectivity.
Repeat the same playbook per site.
Standardize customer setup, support snapshots, policy templates, fleet checks, and handoff documentation.
Deploy extra paths deliberately.
Prepare relay nodes, peer gateways, route intent, direct fallback rules, and validation before traffic moves.
Make advanced control approachable.
Generate named profiles for families, labs, founders, remote teams, travel nodes, and high-privacy devices.
Write conservative operator procedures with preflight checks, explicit risk calls, and rollback notes.
Keep procedures in the project docs so assistants can follow the same install, audit, and recovery flow.
Run every runbook against test gateways, appliance images, bridge nodes, and recovery fixtures before publishing.
Keep baseline runbooks open while selling guided runs, custom packs, MSP templates, and incident recovery.
Platform
The Gateway is built as an operator platform, not a single-purpose router.
A privacy fabric, not a single box.
The Gateway combines bridge relay tooling, traffic-splitting infrastructure, peer nodes, a topology map, managed services, telemetry blocking, identity-aware routes, and regression-backed operations into one staged product surface.
Architecture
Designed as privacy planes, rendered into Linux reality.
Clients
Devices, groups, profiles
Gateway daemon
Policy engine + desired state
Identity plane
DNS plane
Routing plane
Transport plane
Privacy plane
Recovery plane
Control model
Personas, route profiles, privacy classes, trust classes, chains, presets, observers, and gateway nodes are first-class objects.
Execution model
High-level policy renders down into nftables, route tables, DNS behavior, DHCP state, transport paths, and mesh routes.
Feedback model
Reconciliation, drift checks, DNS leak checks, route validation, audit history, live logs, and observers keep intended state honest.
Deployment
Three modes, one model.
Main traffic path
The gateway becomes the default route for downstream devices and owns DHCP, DNS, and policy enforcement, making it the strongest position when full network control is available.
- Best for full network control
- Strongest observability, identity separation, and leak prevention
- Matches full-control gateway deployments
Selective policy gateway
The gateway sits inside an existing LAN and only handles selected devices, a downstream segment, or a controlled micro-network.
- Works when the upstream router cannot be changed
- Useful for incremental adoption
- Preserves the existing network while adding privacy policy control
Travel and public-network mode
A portable deployment for Wi-Fi uplinks, public networks, and constrained environments where the gateway needs to self-protect.
- Designed for client uplink scenarios
- Fits compact hardware, travel routers, and mini PCs
- Keeps hostile-network privacy posture explicit instead of implicit
Control surface
One control plane, multiple entry points.
Network
Dashboard, interfaces, firewall, WiFi, Bluetooth, VLAN, network map, device discovery, and platform state.
Routing
Routing policies, tunnels, splitting, proxies, bridge nodes, traffic chains, mesh coordination, and nodes.
Policy
Devices, groups, profiles, privacy classes, trust classes, segments, presets, exceptions, and secrets.
Operations
Alerts, anomalies, observers, packet capture, live logs, audit, backup, services, health checks, AI assistant, and federation.
Product tour
Daily operation follows the same path as incident recovery.
LAN
Policy
Tunnel
DNS leak guardforced
Route chainsplit + bridge
Fallbackfail closed
Drift checkclean
Model intent
Define which devices, profiles, privacy classes, and route chains belong together.
Preview impact
Validate references, conflicts, fail-open risk, upstream behavior, and fallback posture before applying.
Operate live
Watch map state, logs, service health, packet capture, alerts, bridge paths, and route decisions in one place.
Recover cleanly
Use backups, blue/green deploys, rollback paths, leak checks, and drift checks when conditions change.
Policy lifecycle
The important loop is explicit.
-
01
Model
Operators describe devices, profiles, privacy posture, trust boundaries, and traffic chains as structured objects.
-
02
Validate
The platform checks references, conflicts, fail-open risks, capability limits, and topology assumptions before apply.
-
03
Apply
The control engine applies desired state into routing, DNS behavior, transport managers, and mesh state.
-
04
Observe
Telemetry, audits, leak checks, drift detection, and observers report whether runtime behavior still matches intent.
Trust model
Privacy posture and reachability are treated as operating states.
Unsafe paths should be visible.
Configured kill-switch rules, protected fallback behavior, and leak checks are designed to surface unsafe paths before they become normal.
Name resolution is policy.
Filtering, rewrites, per-device behavior, and upstream choices are controlled alongside routing and privacy posture.
Remote paths are explicit.
Bridge nodes, mesh peers, proxy hops, tunnels, and direct fallback are represented as selectable operating paths.
Claims need evidence.
Path choice, DNS behavior, fallback state, identity separation, and leak checks are visible before the operator trusts the setup.
Deployment readiness
Built for real deployment, rollback, and validation.
Primary gateway mode
Embedded policy gateway
Portable travel gateway
Single-port appliance deployment
Bridge relay deployment
VPS routing node
Systemd hardening
Private validation environment
Structured automation APIAppliance, single-port gateway, VPS node, and bridge relay deployment paths are all represented.
Topology checks, privacy posture review, route/DNS verification, smoke checks, and regression evidence make behavior inspectable.
Kill-switch prestart, systemd pre-starts, blue/green deploy, rollback handling, drift checks, and leak checks reduce risk.
Local policy assistant endpoints are modeled for structured gateway management, not generic chat.
Organization sponsors
Fund the public core. Buy operations when reliability matters.
Keep the basics covered.
Test hardware, domains, CI, release infrastructure, and the public project maintenance floor.
Fund regular maintainer time.
Support triage, documentation, install fixes, operator runbooks, and early privacy posture reports.
Pay for hardening and audits.
Security review, appliance builds, stable release cadence, broader hardware coverage, and recovery testing.
Sponsor The Gateway to fund public maintenance, hardware testing, security review, and install reliability. Paid support stays separate from public roadmap ownership.
Sponsor public maintenanceWays to adopt
Start with trust. Add operations when the network matters.
Early open core
Operators review the local gateway path, validate route and DNS expectations, and prepare hardware before public install.
Sponsors and Pro
Serious operators fund maintenance, get better notes, receive guided setup help, and shape public priorities through evidence.
Appliances and managed ops
Users who want outcomes instead of assembly pay for signed builds, backup, update help, monitoring, and recovery.
MSP and business
Consultants and teams pay for repeatable fleet workflows, templates, support boundaries, and commercial SLAs.
Support model
Guided help stays explicit about ownership, proof, and recovery.
The operator keeps the path decision.
Support can review intended routes, bridge paths, and fallback choices, but live traffic ownership and final approvals stay with the operator.
Resolver behavior stays named and inspectable.
Support guidance should preserve who owns DNS, what upstreams are allowed, how fallback behaves, and what per-device evidence proves the result.
Claims need redacted evidence.
Privacy-sensitive guidance should be tied to route, DNS, leak, and fallback checks instead of vague assurances. Logs and bundles should stay operator-generated and redacted.
Risky changes need a known-good way back.
Before support touches route, DNS, firewall, or remote-access settings, the recovery path, rollback owner, and stop conditions should already be clear.
Open guided support only after the operator can name the owners and the way back.
The Gateway support is meant to help with review, validation, and bounded change windows. It should start after the operator identifies who owns the route, who owns DNS, how fallback should behave, what evidence defines the intended privacy posture, and what recovery path stops the session if risk increases.
Record the current route owner, DNS owner, fallback owner, and final approver before any live change begins.
Bring route traces, DNS behavior, fallback expectations, leak checks, and only the redacted evidence needed for the request.
Keep console, SSH, or local access plus a known-good rollback target so support stops immediately if safe recovery is no longer clear.
Operating boundaries
Keep ownership, fallback policy, and recovery responsibility explicit.
Route ownership stays with the operator.
Support can review intended path changes and validation evidence, but the operator owns the active route decision and final apply approval.
Proof: path trace, intended egress, stop conditions.Resolver ownership remains named.
DNS upstreams, per-device policy, and bypass handling should stay inspectable so guided help does not obscure who controls resolution.
Proof: resolver map, upstream list, leak checks.Fallback behavior should be chosen, not guessed.
Whether traffic blocks, degrades, or reroutes during failure should be declared before a change window starts, along with who can alter that policy.
Proof: fallback trigger, fail-open risk, rollback target.Support stops when the way back is unclear.
Console, SSH, or local recovery access plus a known-good rollback point should exist before support touches route, DNS, firewall, or remote access state.
Proof: recovery path, owner, last known-good snapshot.Use the public boundary documents to define route ownership, DNS ownership, privacy posture evidence, support scope, and rollback responsibility before guided setup starts.
Ways to use The Gateway
Open where trust matters. Paid where operations matter.
Early Open Core
Self-hostedPrepare a local install, review the trust model, and contribute hardware profiles, docs, policies, and fixes as the public repo opens.
Request install readiness reviewSupporter
VoluntaryFund maintenance, hardware testing, audit work, public roadmap notes, and early operator feedback cycles.
Sponsor the projectPro Support
Scoped supportGuided install, upgrade help, recovery review, support intake, and policy guidance. Operators keep control of credentials, traffic paths, and final approvals.
Request guided setupSigned Build
Founding builds by requestSigned image or preconfigured device with validation, backup/restore, hardware fit review, and optional setup support.
Join appliance waitlistDesign Partner
Pilot pricingFleet workflows, customer templates, operator runbooks, support boundaries, and paid onboarding for repeat deployments.
Apply for MSP pilotEarly access program
Trust, proof, and operational help move together.
Make the trust model visible.
Publish install docs, security boundaries, product screenshots, operator workflows, roadmap, and contribution path.
Fund the shared layer.
Use recurring sponsors, public funding goals, hardware test funds, audit funds, and public maintenance milestones.
Add reliability around the core.
Offer guided setup, Pro support, appliance fit review, managed operations, and MSP onboarding for early operators.
Turn operations into repeatable playbooks.
Publish guided runbooks for provisioning, privacy audit, identity separation review, recovery, bridge nodes, and policy templates. The first install/provision runbook is now linked as a public prototype.
Install
Install readiness
Trust
Security boundaries
Support
Support intake
Sponsors
Sponsor path
Verification
Public test evidence
Redaction
Support bundle guide
QA
Site QA gate
Product proof
Broad enough for daily operation, specific enough to verify.
- Engine
- Gateway engine target: policy, transport, DHCP, DNS, and enforcement layers exposed through public launch evidence.
- Control UI
- Early access should include screenshots or demo clips for network, routing, privacy, security, monitoring, and operations views.
- Automation
- API surface map is prepared across network, policy, privacy posture, transport, bridge, and federation areas; public docs should expose it before broad release.
- Evidence planned
- Evidence checklist covers topology, privacy posture, deployment, recovery, and regression proof needed before broad release.
Platform maturity
A serious foundation with a clear hardening path.
Core gateway
Core gateway operation is the first public readiness target: DHCP, DNS, firewalling, policy routing, and enforcement represented end to end.
Control platform
Policy objects, web UI, automation API, CLI, mesh, observers, backups, and deployment paths move next through public evidence and hardening.
Advanced platform
Advanced platform work stays staged until federation, broader hardware coverage, and cryptographic roadmap items have dedicated infrastructure.
Control depth
Map, splitting, bridges, telemetry block, services, and nodes are staged as first-class product surfaces.
Hardening path
Continue strengthening settings reads, federation sync, telemetry coverage, bridge traffic visibility, and routing apply semantics.
FAQ
Useful boundaries before anyone installs it.
Is this a VPN replacement?
No. The Gateway can use VPNs as transports, but the product is about route intent, DNS behavior, identity separation, fallback posture, privacy classes, and recovery around those transports.
Does it promise anonymity?
No single gateway can promise anonymity by itself. The Gateway helps build privacy-sensitive setups by controlling identity separation, DNS, routes, transports, fallback, and leak checks in one inspectable model.
What does it not hide?
It does not hide identity from logged-in services, browser fingerprinting, payment trails, endpoint compromise, or a malicious remote relay. Reports should show assumptions, active paths, DNS behavior, known leaks, and operator-owned risks.
Can it run without cloud services?
Yes. The local open core is the trust anchor. Managed backup, fleet visibility, support, and appliances are optional paid operational paths.
Do managed services inspect traffic?
They should not need to. Support should use customer-generated, redacted bundles with explicit export approval, time-limited access, and revocation.
Who should not use it?
Do not rely on The Gateway as a one-click anonymity product, a substitute for endpoint security, or a way to make logged-in accounts, payments, browser fingerprints, or compromised devices private.
What if a policy breaks networking?
The operating model is built around preview, validation, drift checks, backups, rollback paths, and safe recovery instead of blind configuration changes.
Product direction
Self-hosted, privacy-first, and explicit about what traffic is doing.
The Gateway is designed for people who want to build their own overlay above the internet: local control first, privacy posture visible, privacy claims testable, and paid operational paths when reliability, recovery, fleet visibility, or support become critical.