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:portdestinations 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.
Do you need one?
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.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
- An administrator adds an Outpost under Config -> Outposts and installs it with the guided setup.
- 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.
- 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.
- The Outpost checks each request against its own
ALLOWED_DESTINATIONSand 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.
Next steps
Install an Outpost
Add an Outpost, choose where it runs, and confirm it connects.
Connect a system through an Outpost
Route a connection, keep its credentials in your own secret store, and test routes.
Security
Who can do what, what the Outpost refuses, and what Genesis stores.
Troubleshooting
What each Outpost status means and how to fix it.

