Exorails Connect — private networks

How it works

You install exorails-connect on a Linux machine that can see the target (a bastion, a small VM in the VPC, the database host itself). It only makes outbound HTTPS connections to Exorails, so there is nothing to open on your firewall and no public IP to allow-list.
You declare routes on the machine: a name, a host and a port (db → 10.0.1.12:5432). The agent refuses to dial anything else, whatever the gateway asks.
You attach the machine to one or more environments, optionally restricting each environment to a subset of the routes. When you add a connector to that environment, the setup form gains a Reach via choice: pick the machine and the route, and the connector dials through the tunnel instead of the public internet.
The connection to your database is end-to-end: TLS to Postgres, SQL Server or Elasticsearch is negotiated between the gateway and your server through the tunnel, the relay only carries bytes it cannot read.

Install (Linux, 2 minutes)

Open the environment's Private network tab and click Add a machine. You get a one-time enrollment token (valid 15 minutes) and the install command:

curl -fsSL https://api.exorails.net/connect/install.sh | sh -s -- --token exe_…

The script downloads the binary for your architecture (amd64 or arm64), verifies its checksum, installs it as a systemd service running as an unprivileged user, and enrolls the machine. The machine appears in the tab as soon as it connects. Without curl | sh, download exorails-connect-linux-amd64 or -arm64 from https://api.exorails.net/connect/dist/ and run:

exorails-connect up --token exe_… --name bastion-eu
exorails-connect status

Enrollment gives the machine its own credential, stored in /etc/exorails/connect.json (mode 0600). The enrollment token is consumed; it cannot be reused. The agent reconnects by itself after a network blip or a reboot.

Declare routes

From Machines (organization level) add the hosts the machine may reach. Private addresses are fine here, that is the point; loopback and cloud metadata addresses are refused. One machine can hold many routes and serve many environments.

db        10.0.1.12:5432     PostgreSQL in the VPC
analytics warehouse.internal:8443   ClickHouse
cache     10.0.1.40:6379     Redis

Use a route from a connector

In the environment's Tools tab pick a connector (PostgreSQL, MySQL, SQL Server, ClickHouse, Redis, MongoDB, Elasticsearch, SSH, Kubernetes, Prometheus, S3-compatible, REST or GraphQL API), choose the machine and route under Reach via, and paste the credential exactly as you would for a public host, using the private address:

postgres://readonly:…@10.0.1.12:5432/app?sslmode=require

The host in the credential must match the route; a mismatch is refused before any byte is sent. Everything else is unchanged: read-only by default, bounded output, one call logged per tool call.

Security model

Outbound only. The agent dials wss://mcp.exorails.net; nothing listens on your machine.
Allow-list, not a VPN. The tunnel is application-level: one TCP stream per connector call, only to a declared host:port, only for an environment the machine is attached to. There is no network to route, no subnet exposed.
Revocable in one click. Disable the machine and every tunnel drops; delete a route and connectors using it stop; detach an environment and its connectors lose the path. The credential of a disabled machine is refused at the door.
Auditable. Each machine keeps an event log (connects, disconnects, refused targets) visible in Machines, and every tool call is in the environment's call log as usual.

Limits and roadmap

Linux amd64 and arm64 today (any distribution with systemd). macOS is next; Windows later.
A connector added through a machine is validated on its first call rather than at setup, since the probe runs on the public path.
Latency: one extra hop through the relay, typically a few milliseconds inside Europe. Sessions stay open, so a query costs the same as it does on the public path after the first call.

Back to connectors →