Skip to main content
Once an Outpost is installed and connected (see Install an Outpost), any connection whose system sits behind it can use it. Nothing else about the connection changes: it keeps its real host name, port and TLS settings.

​
Route a connection through an Outpost

  1. Open Config -> Connections and create a connection, or edit an existing one.
  2. Enter the system’s details as usual, for example host db.corp.internal, port 5432.
  3. Under How does Genesis reach this system?, choose Through a Genesis Outpost and pick the Outpost.
  4. Click Test Connection, then save.
The other answer, Directly, means over the internet or from inside the network Genesis runs in. Choose it for public services, and for systems your own Genesis installation can already reach. Genesis resolves each host name the same way for every connection. If another connection routes a host through an Outpost, a connection set to Directly reaches that host through the same Outpost too. Creating or changing a connection to newly reach a host this way is refused unless you can route through that Outpost; even with permission, a direct connection cannot be saved while another connection routes the host. Use Through a Genesis Outpost with that Outpost, or use a distinct host name or the system’s IP address for a direct connection. The same rule prevents routing a host through an Outpost while another connection reaches it directly. An Outpost routes by host name, so a connection that chooses one must use a DNS name, not an IP address. Genesis refuses to save a new connection with an IP address through an Outpost, and refuses to use an older saved connection if its chosen Outpost is deleted, routing is off, or it has no usable route for the host; Genesis never falls back to dialing that host directly. Move the connection to a usable Outpost, or choose Directly only when Genesis can reach the host itself. Do not use an Outpost tunnel listener address as a system host. Genesis refuses those reserved addresses; enter the system’s own host name and, if it is inside a customer network, choose Through a Genesis Outpost. If there is no Outpost yet, administrators can choose Set up a new Outpost… in the Outpost list. The guided setup opens over the form and, once the Outpost connects, returns you to the connection with that Outpost selected. When the Outpost you pick is down, the form says so under the picker, with the cause and the fix.
Choosing an Outpost for a connection needs permission to route through it. Administrators always have it; an administrator can grant it to other roles per Outpost (see Who can route through an Outpost). Without it, the Outpost option is disabled and shows Ask an admin to grant access to an Outpost. Using a connection someone else already routed only needs the usual connection permissions.
When a test of a connection set to Directly fails because its host does not resolve or times out, which is how a private host looks from outside your network, the form may show Can’t reach this directly. Is it inside your network? with a Try through Outpost <name> button. Clicking it re-tests through that Outpost and keeps the choice on the form.

​
Route a whole domain

Instead of choosing the Outpost on each connection, an Outpost can route a whole domain. On the Outposts page, click Edit on the Outpost, open Advanced: route a whole domain, and enter host patterns, one per line:
Every connection to a matching host then goes through this Outpost, even if it did not choose it, unless the connection chose a different Outpost: a connection’s own Outpost choice takes precedence over another Outpost’s pattern. Two connections that choose different Outposts for the same host still conflict, and that is refused (see below). A pattern may not newly cover a host that saved connections reach through another Outpost, whether they chose it or an earlier Outpost’s pattern routes them: the save is refused, naming the host and the Outpost, so a host name keeps one Outpost. The connection form shows Private host? Connections to hosts served by an Outpost … are routed through it automatically so users know. Leave the patterns empty to route only the connections that choose the Outpost; the per-connection choice is the recommended default. Genesis allows only one way to reach a host name across connections: through one Outpost or directly. This includes when patterns overlap, and Genesis refuses connection saves or pattern changes that would create a conflict. For how Genesis handles an existing conflict, see Outpost Troubleshooting.

​
Use a secret from the Outpost

A connection’s password or other secret can stay in your own secret store. Instead of the secret value, the connection stores a reference, and the Outpost reads the value from your store each time Genesis connects:
For example, outpost_acme-prod/genesis/postgres-prod#password asks Outpost acme-prod for the password field of the JSON secret genesis/postgres-prod. Leave out #<field> when the secret is a plain value. In Azure Key Vault and Google Secret Manager, whose names cannot contain /, that secret is named genesis--postgres-prod (each / becomes --); the reference keeps the /. To add one in the form:
  1. Choose Through a Genesis Outpost and pick the Outpost.
  2. Under the secret field, click Use a secret from the Outpost.
  3. Enter the Secret name and, optionally, the Field. The form previews the reference.
  4. Click Insert reference, then test and save the connection.
The Outpost must allow it: its OUTPOST_CAPABILITIES includes secrets, and the secret name starts with its ALLOWED_SECRET_PREFIX (see Keep credentials in your own secret store). If you switch the connection back to Directly while it holds a reference, the form warns you: the reference can only be read through the Outpost.

​
See which connections use an Outpost

On Config -> Connections, a connection routed through an Outpost shows a via Outpost <name> property on its row. If Genesis last saw that Outpost down, the row’s status changes to Outpost down instead; hover over the status for the cause and fix. This status takes priority over setup or connection-health statuses. See Connections — Finding connectors and saved connections for the other row statuses.

​
Test routes

Each Outpost’s card on Config -> Outposts shows its status (Connected, Not connected, Connected, with problems or Unknown), its slot, who can route through it, and how many routes it holds.
  • Test routes tests every route the Outpost holds. Show routes lists each destination, the connections that use it, and a Test button for that route alone.
  • Check another host… tests a host and port that no saved connection uses yet. The Outpost looks the name up and opens a TCP connection to it from inside your network, and the result shows whether it is allowed, what it resolved to and how long the connection took.
A route test reaches only the host and port you name, and only if the Outpost’s ALLOWED_DESTINATIONS allows it.

​
Ask Eve

Eve, the Genesis system agent, can set up and check Outposts for administrators. For example:
  • “Help me set up an Outpost for our on-prem Postgres.”
  • “Check route: can Outpost acme-prod reach db.corp.internal on port 5432?”
  • “Explain routing: will my connection to jira.corp.internal go through an Outpost?”
  • “Why is Outpost acme-prod down?”
Eve uses the same checks and diagnoses as the Outposts page. She never asks you to paste a private key, secret or password into chat.