Docs

What Gateway actually does today, in enough detail to use it without guessing.

Getting started

  1. Sign in with an identity provider configured for this deployment. Gateway creates your account on first sign-in; there is nothing to register separately.
  2. Add a server: give it a name, hostname, port, SSH username, and a connection region. Gateway generates an Ed25519 SSH identity for it automatically.
  3. Copy the generated public key from the server's SSH identity tab and append it to the target account's authorized_keys file yourself. Gateway does not connect to the server to do this for you. The line looks like this:
    ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIKk3f9…redacted…7fQe gateway:srv_2Y8QK1M
  4. Rotate or revoke the identity at any time from the same tab. Both actions require a recent step-up reauthentication.

Regions

A region is a connection boundary, not a data center guarantee. Each region publishes the IPv4 and IPv6 addresses a future executor in that region would connect from, so you can allowlist them on your own firewall ahead of time.

Files

File transfer is one-way: server to Gateway, never the reverse. A regional executor pulls a file off a server over SSH and uploads it directly; nothing arrives until an executor exists to do the pulling, so this is not live yet. Once it is, every file is addressed only by internal identifiers and returned only to the account that owns it.

Activity

Every sign-in, identity change, file operation, and billing event is written to an append-only log, visible per-server and account-wide. Nothing is ever edited or removed from it by application code, even when the resource it describes is later deleted.

Known limitations