> ## Documentation Index > Fetch the complete documentation index at: https://docs.genesiscomputing.com/llms.txt > Use this file to discover all available pages before exploring further. # Connect a System Through an Outpost > Route a Genesis connection through an Outpost, keep its credentials in your own secret store, and test routes. Once an Outpost is installed and connected (see [Install an Outpost](/docs/Setup/Outposts-Install)), 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](/docs/Setup/Outposts-Security#who-can-do-what)). 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 \** 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: ```text theme={null} *.corp.internal db01.corp.internal ``` 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](/docs/Setup/Outposts-Troubleshooting#diagnoses). ## 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: ```text theme={null} outpost_/# ``` 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 `#` 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](/docs/Setup/Outposts-Install#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 \** 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](/docs/Setup/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.