> ## 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.
# Genesis Outposts
> Let Genesis reach databases and services inside your private network through a small program you run there. Outbound-only, no inbound ports.
## What an Outpost is
A **Genesis Outpost** is one small program you run inside your own network: on a VM, in
Docker, in Kubernetes, or on a laptop to try it out, in AWS, Azure, GCP or your own data
center. It connects **out** to Genesis and gives Genesis a guarded path to the systems you
choose behind your firewall.
* **Outbound only.** The Outpost dials Genesis over HTTPS (port 443). You open no inbound
port, and your traffic does not pass through infrastructure Genesis runs.
* **You set the ceiling.** The Outpost reaches only the `host:port` destinations you list in
its own settings (`ALLOWED_DESTINATIONS`), whatever Genesis asks for.
* **Credentials can stay home.** A connection can store a reference to a secret instead of
the password. The Outpost reads the value from your own secret store at connect time.
* **Nothing else changes.** A connection routed through an Outpost keeps its real host name,
port and TLS settings. Agents, missions and apps use it like any other connection.
Outposts work with any connector that takes a host or URL: databases such as PostgreSQL,
SQL Server, MySQL or Oracle, Jira and Confluence Data Center, self-managed GitLab, and
internal HTTP APIs.
## Do you need one?
| Where Genesis runs | Your system is… | Choose |
| - | - | - |
| Databricks (App) | inside your private network or VPC | **Through a Genesis Outpost** |
| Anywhere | on the public internet (SaaS APIs, cloud warehouses) | **Directly** |
| Your own VPC or data center | reachable from the network Genesis runs in | **Directly** |
| Your own VPC or data center | in another network Genesis cannot reach | **Through a Genesis Outpost** |
If you installed Genesis inside your own VPC, it can usually reach your systems directly and
you do not need an Outpost. An Outpost is for the case where Genesis runs somewhere your
private network does not reach, typically inside Databricks.
The Snowflake Native App supports Outposts from release 1.19.97, which exposes the
`outposttunnel` endpoint the Outpost dials. An older Native App does not, so its Outposts page
shows them as unavailable and they cannot be switched on until the app is upgraded. Outposts
are also available when Genesis runs in Docker, Kubernetes or as a Databricks App. For the
SPCS tunnel listener's addresses and port, see [Snowflake Native App installation and
configuration](/docs/deployments/Snowflake-Native-App/Installation-And-Configuration).
A Genesis Databricks App supports Outposts from version 1.19.97, which runs the Outpost tunnel
and resolves the private host names an Outpost routes. An older App answers `/outpost-tunnel`
with HTTP 503 and reports routed names as `names_unresolvable`; upgrade the App to use an
Outpost. Outposts need Outpost 0.7.0 or later.
## How it works
```text theme={null}
Your network Genesis
┌─────────────────────────────┐ ┌──────────────────────────────┐
│ │ HTTPS (443) │ │
│ Genesis Outpost ──────────┼───── outbound ────►│ Outpost tunnel endpoint │
│ │ │ one WebSocket, │ (Databricks App or │
│ │ only ALLOWED_ │ signed in │ your own host) │
│ │ DESTINATIONS │ │ │
│ ▼ │ │ Connections, agents, apps │
│ db.corp.internal:5432 │ │ use db.corp.internal:5432 │
│ jira.corp.internal:443 │ │ as if it were local │
└─────────────────────────────┘ └──────────────────────────────┘
```
1. An administrator adds an Outpost under **Config -> Outposts** and installs it with the
guided setup.
2. The Outpost signs in to Genesis with its own identity (for a Databricks App, its own
service principal), then inside the tunnel with its own tunnel key, and holds the
connection open.
3. When you create a connection and answer **How does Genesis reach this system?** with
**Through a Genesis Outpost**, Genesis asks that Outpost to carry traffic to the
connection's host and port.
4. The Outpost checks each request against its own `ALLOWED_DESTINATIONS` and opens a
connection to the system from inside your network.
### The tunnel
Each Outpost holds **one WebSocket** to Genesis, opened through the same front door as the
Genesis UI (`/outpost-tunnel`), and speaks Genesis's own tunnel protocol over it
(`genesis-outpost.v1`):
* **Mutual sign-in.** Genesis and the Outpost each prove they hold the Outpost's tunnel key,
by answering a fresh challenge. The key never crosses the network.
* **Many connections, one WebSocket.** Each connection Genesis makes to a routed system is
its own stream inside the WebSocket, with its own flow control, so one large transfer does
not hold up the others.
* **One direction.** Only Genesis opens streams, and only toward routes the Outpost itself
declared. The Outpost cannot open a stream toward Genesis, and Genesis cannot ask it to
reach anything outside its `ALLOWED_DESTINATIONS`.
* **Only Genesis's own processes.** Inside Genesis, a routed connection is accepted only
from Genesis's own processes, not from code that agents run; see
[Security](/docs/Setup/Outposts-Security#who-can-use-a-tunnel-listener).
The tunnel is built into Genesis: nothing extra runs beside it. See
[Tunnel limits](/docs/Setup/Outposts-Security#tunnel-limits) for the connection limits
Genesis applies.
Routing is event driven: Genesis sends an Outpost its routes when a connection that uses it
is created, changed or deleted, when Genesis starts, and again whenever a request finds the
Outpost unreachable. An Outpost that restarts restores its last routes on its own.
## Next steps
Add an Outpost, choose where it runs, and confirm it connects.
Route a connection, keep its credentials in your own secret store, and test routes.
Who can do what, what the Outpost refuses, and what Genesis stores.
What each Outpost status means and how to fix it.