How WingGate Works

WingGate's structure fits in one sentence: a service that decides who can do what, a wing-connector that runs inside your own network, and the clients in your hands. Once you see how these three divide the work, everything else falls into place.

The big picture

Who does what

Component	Where it lives	What it does for you
Web Console	Your browser	The one place to manage everything: accounts, organizations and projects, assets, connectors, grants and audit. Nothing to install.
WingGate service	WingGate cloud	The brain: verifies who you are, decides who may reach which asset, issues short-lived credentials, and records every access in the audit log.
wing-connector	Your network	A lightweight proxy deployed next to your assets. It dials out to the service and is the only component that ever touches your assets.
Tool Runner (optional)	On the asset	Installed on demand via a controlled job: git inspection, file search (find/grep) and runtime snapshots run locally on the asset — only the results travel back.
Browser extension (optional)	Your browser	The execution end of your browser asset: it brings your browser under management and lets AI operate it safely — page snapshots, controlled clicks and form fills.
Clients	Your devices	Web Terminal, your own SSH client, MCP clients such as Claude Code — connect the way you prefer.

Why the wing-connector matters

The wing-connector shapes what WingGate's trust boundary looks like from your side. It dials out to the service (outbound-only, mutual TLS), so:

• Your machines need no public IP and no inbound firewall rules — a home lab, a private VPC, office machines: all directly manageable.
• The connector stays inside your trust boundary, close to the assets it serves; credentials and asset-side access never leave your network.
• The service adds zero exposure to your assets: even if the WingGate cloud is unreachable, your machines have not opened a single extra port.

See connector deployment for installation and operation.

Tool Runner: the on-asset executor

• What it is — a small executor installed on demand on the asset itself (into the chosen connection profile's user cache directory, never with sudo). Not a resident service, and it does not change your asset's security boundary.
• What it does — git inspection, file search (find/grep) and runtime snapshots run locally on the asset; only results travel back — never whole files, never copies of your code.
• When it appears — not installed by default. The first Runner-only operation creates an installation Job (the console shows installing; the original operation retries automatically). Basic file operations on SSH / host assets always use zero-install SFTP and never trigger it. The Runner belongs only to assets that have a host to install on: SMB / WebDAV / S3 file backends speak their own protocol directly and have no such installation path.
• Authorization and updates — installation requires explicit authorization per project × asset × connection profile; managed-channel updates are automatic, but a changed install path or trust root requires re-authorization; revoking stops future installs and updates, it does not remove the existing binary.

Where data goes — and what never passes through the service

WingGate separates deciding from moving:

• The service only decides — authentication, authorization, credential issuance, audit.
• Data goes direct — SSH sessions, file bytes and MCP tool payloads flow between your clients and the wing-connector, not through the service. That means faster transfers and a crisp responsibility boundary.
• Two exceptions: Web Terminal is bridged through the service's session stream in exchange for a zero-install, anywhere experience; and browser tools are executed by the extension in your own browser — your browser is onboarded as a browser asset, and this traffic never touches the wing-connector in your network.

Two typical journeys

Connecting to a host over SSH

1. Before the first connection, confirm the asset's host key fingerprint in the console (anti-man-in-the-middle; verified automatically afterwards).
2. Your SSH client connects to WingGate's SSH endpoint.
3. The service verifies your public key and project grant, then hands the session to the wing-connector over the reverse channel.
4. The wing-connector connects to the target host locally, and your shell opens.
5. The whole session appears in the audit log — who, when, from which entrypoint, and what was accessed.

Letting an AI read a file

1. You create a project-scoped MCP credential in the console and configure it in Claude Code or another client.
2. The AI requests the file over MCP; the wing-connector checks the project authorization.
3. The read executes on the asset side and the content returns over the data plane; large files are paginated with a hard byte cap — never unbounded transfer.
4. The access is audited; you can revoke the credential in the console at any time.

Where to next

• Start from the browser: Using the Web Console
• Install a connector and onboard your first assets: connector deployment
• Go deeper on connections and trust boundaries: Connection model
• Let AI use your assets safely: Setting up MCP access