Skip to main content
The guided setup on Config -> Outposts gives you only the commands for the place you choose, with your Genesis endpoint and the Outpost’s settings already filled in. This page explains each step so you know what you are running and why.
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.
Setting up an Outpost needs a Genesis administrator. For Snowflake deployments you also need someone who can create users and roles in the Snowflake account (for example ACCOUNTADMIN).

​
Before you start

  • Outbound HTTPS. The machine that runs the Outpost must be able to open outbound HTTPS (port 443) to the Genesis tunnel endpoint shown in the setup. For Snowflake it also signs in at https://<orgname>-<account_name>.snowflakecomputing.com. An outbound proxy is supported through HTTPS_PROXY and NO_PROXY.
  • Network reach. From that machine, the systems you want Genesis to use (for example db.corp.internal:5432) must resolve and accept connections.
  • Resources. The Outpost is a single binary of about 13 MB and needs around 64 MB of memory and a fraction of a CPU.

​
Turn on Outposts

Outposts are off until an administrator turns them on. Open Config -> Outposts and switch Outposts on. While they are off, nothing is routed through any Outpost.

​
Add and install an Outpost

1

Name your Outpost

Click Add Outpost and give it a name such as acme-prod: lowercase letters, digits and -. The name cannot be changed later.You choose which systems use the Outpost on each connection, so nothing else is needed here. Under Advanced: route a whole domain you can optionally send every connection to matching hosts through this Outpost; see Route a whole domain.
2

Choose where it will run

For a laptop or VM, pick the operating system and processor. For Kubernetes, pick the namespace (default genesis-outpost).For a VM, Docker or Kubernetes you can fill in Systems Genesis may reach through it: a comma-separated list of host:port entries such as db.corp.internal:5432, jira.corp.internal:443. It becomes the Outpost’s ALLOWED_DESTINATIONS; see Allowed destinations. You can also leave it empty and fill it in on the host.For VM, Docker or Kubernetes, you can also enable Read connection secrets from your own store; it is off by default and is not offered for laptop evaluation. Choose AWS Secrets Manager, Azure Key Vault or Google Secret Manager and set the secret-name prefix (default genesis/). AWS is selected by default; Azure can use the generated Key Vault URL placeholder or a URL you provide, while the Google Cloud project is optional. The wizard generates the Outpost settings for that store; give its cloud identity read access as described in Keep credentials in your own secret store.
3

Set up how it signs in to Genesis

The setup shows the identity steps for where your Genesis runs. See How the Outpost signs in.
4

Install it

Run the install commands shown, in order. Replace any <placeholder> first. Then click I’ve installed it. See What the install does.
5

Wait for it to connect

Genesis checks every few seconds for up to 10 minutes. When the Outpost connects, the setup shows its reported release version (when available), capabilities and the number of destination routes it holds. Older releases may not report a version. This count excludes the Outpost’s own tunnel control channel; zero means no connection is using the Outpost yet. If it does not connect, the setup shows why; see Troubleshooting.
6

Try it

Enter a host and port inside your network and click Test route. The Outpost resolves the name and opens a TCP connection from inside your network, and Genesis shows the result. Then click Create a connection to open the provider picker. When you select a provider with a host field, the new connection form starts with this Outpost selected; providers without a host field connect directly. If you started from the connection form, click Use this Outpost instead.
To reinstall or move an existing Outpost, click Install on its card on the Outposts page. The setup starts at Where will it run?.

​
How the Outpost signs in

Each Outpost has its own identity. Which one it uses depends on where Genesis runs. The tunnel endpoint requires an Outpost release that offers the genesis-outpost.v1 protocol (0.7.0 or later); older releases receive HTTP 400 and cannot connect.
Needs Genesis Native App release 1.19.97 or later. The Outpost dials the app’s outposttunnel endpoint; the setup fills in GENESIS_ENDPOINT with its ingress URL (https://<id>-<account>.snowflakecomputing.app), looked up in Snowflake. Snowflake’s ingress signs the Outpost’s service user in before the connection reaches Genesis.
The Outpost signs in as a dedicated Snowflake service user with a key pair. The setup generates the SQL for you. It:
  1. Creates a role that holds only the Genesis application role APP_OUTPOST_TUNNEL, which allows nothing but connecting to the Outpost tunnel endpoint.
  2. Creates the service user (for Outpost acme-prod, GENESIS_OUTPOST_ACME_PROD) with no password.
  3. Creates a network policy that pins the user to your Outpost’s egress IP address.
  4. Registers the Outpost’s public key on the user.
Where the key pair is made depends on the target:
  • VM (Linux), Docker, Kubernetes: the setup’s first step generates the key pair with openssl on the machine that will run the Outpost, and the SQL registers it in the same run. On Kubernetes the private key goes into a Kubernetes Secret.
  • Laptop: outpost init generates the key and prints the ALTER USER statement with the key filled in. Run it as printed.
  • Windows VM: outpost keygen generates the key after the download and prints the statement.
Keep the network-policy step for production: a stolen key is then useless from any other address. For a laptop trial whose IP address changes, you can leave out the two network-policy statements.
The private key never leaves your network. Keep it in a secret store or a Kubernetes Secret, never in an environment variable, a container image or shell history, and never paste it into Genesis or a chat.
Behind the Snowflake ingress the Outpost also signs in inside the tunnel with its own tunnel key: in the setup’s sign-in step choose New tunnel key (or, for an existing Outpost, Install on its card, then New tunnel key). Genesis shows the key once; give it to the Outpost as OUTPOST_TUNNEL_KEY and keep it in a secret store. The ingress admits any Snowflake user granted APP_OUTPOST_TUNNEL; behind it the key signs in only this Outpost and opens only this Outpost’s own addresses.

​
Each Outpost’s tunnel key

Every Outpost has a tunnel key of its own (Outpost 0.7.0 or later). It signs in only that Outpost, opens only that Outpost’s own addresses inside Genesis, and proves each of its answers to Genesis with the key, so Genesis knows which Outpost answered. The sign-in is a challenge-response in both directions: the key never crosses the network, and the Outpost checks that the endpoint holds the same key before it carries anything. Genesis keeps the key in its secret store and shows it once, when it is issued; issuing a new one replaces it at once. That Outpost is refused until it restarts with the new key. The other Outposts keep their keys and stay connected.
An Outpost signs in only with its own key, on every deployment model: there is no shared key and no sign-in without a key. Outpost 0.7.0 or later is required, and it refuses to start without its own tunnel key. An Outpost before 0.7.0 cannot connect to Genesis’s tunnel; upgrade it. Until its key is issued an Outpost cannot connect, and the Outposts page says so on its card; issue the key (Install, then New tunnel key), set it on the Outpost, and start it on Outpost 0.7.0 or later.

​
What the install does

Every install downloads the same Outpost from the public release page, github.com/genesis-computing-ai/genesis-outpost/releases, or runs the container image ghcr.io/genesis-computing-ai/genesis-outpost built from it. The current install is Outpost 0.7.0, which uses only the native genesis-outpost.v1 tunnel protocol; it does not use Chisel. Binaries are published for Linux, macOS and Windows on x64 and ARM, with a SHA256SUMS file beside them. The install commands check the download against SHA256SUMS before installing it.
  1. Download the binary for your machine and check it against SHA256SUMS.
  2. Run ./outpost init (Windows: .\outpost.exe init). It asks for the tunnel endpoint URL and slot, how the Outpost signs in, and which host:port destinations Genesis may reach through your machine. The setup page lists the answers to give. It writes outpost.env in your user config directory, readable by you only.
  3. For Snowflake, run the ALTER USER statement outpost init printed.
  4. Run ./outpost run. It prints an evaluation-mode banner naming what it exposes, then every request Genesis makes. Stop it with Ctrl-C.
Nothing is installed as a service and nothing starts on login. Evaluation mode enforces the same security checks as production.
The binaries are not yet code-signed. On macOS the install command removes the download quarantine flag after the checksum passes (or allow it under System Settings -> Privacy & Security). On Windows, if SmartScreen warns, choose More info, then Run anyway.
  1. Download the binary to /usr/local/bin/outpost and check it.
  2. Write its settings to /etc/genesis-outpost/outpost.env, readable by root only.
  3. Create an unprivileged genesis-outpost system user and a genesis-outpost systemd service with Restart=always, then enable and start it. Follow its log with sudo journalctl -u genesis-outpost -f.
systemd starts the Outpost at boot and restarts it if it stops.
  1. Download outpost.exe to C:\Program Files\genesis-outpost and check its hash.
  2. For Snowflake, run outpost keygen, then have a Snowflake administrator run the ALTER USER statement it prints.
  3. Write the settings to C:\ProgramData\genesis-outpost\outpost.env, readable only by SYSTEM and administrators.
  4. Create a scheduled task, Genesis Outpost, that starts it at boot as SYSTEM.
The Outpost does not register itself as a Windows service. To restart it after a crash, set If the task fails, restart every 1 minute on the task, or run it under a service wrapper such as NSSM.
One docker run command starts the container genesis-outpost-<name> with --restart unless-stopped, its settings as environment variables, a named volume for its saved routes, and (for Snowflake) the private key mounted read-only. Follow its log with docker logs -f genesis-outpost-<name>.The image is distroless (the binary and CA certificates only) and runs as a non-root user.
Save the generated manifest, replace any <placeholder>, and apply it:
It creates a namespace, a service account, a Secret holding the sign-in settings, and a one-replica Deployment that runs as non-root with a read-only root filesystem and no Linux capabilities. For the secrets capability, give the pod your cloud’s workload identity: on EKS, annotate the service account with an IAM role (IRSA); on AKS, annotate it with azure.workload.identity/client-id: <managed identity client ID> and label the pod azure.workload.identity/use: "true"; on GKE, annotate it with iam.gke.io/gcp-service-account: <gsa>@<project>.iam.gserviceaccount.com.The saved routes live in an emptyDir, so a rescheduled pod starts with none. Genesis re-sends its routes the next time a query or connection test through it fails to open, and in its hourly check. Use a small PersistentVolumeClaim instead if you want routes to survive rescheduling immediately.

​
Outpost settings

The setup fills these in for you. You change them in the Outpost’s settings file, container environment or Kubernetes manifest, then restart it. An Outpost that cannot use its settings (no slot, an unreadable key, two sign-in methods at once) stops at startup with a log line naming the problem.

​
Allowed destinations

ALLOWED_DESTINATIONS is your ceiling. The Outpost reaches only what it lists, whatever Genesis asks for, and reports anything else as refused. List a host:port for each system; wildcards work:
Cloud metadata services and link-local addresses are never reachable through an Outpost, even if you list them. See Security.

​
Keep credentials in your own secret store

To let connections read passwords from your own secret store instead of storing them in Genesis:
  1. Set OUTPOST_CAPABILITIES=tunnel,secrets.
  2. Set ALLOWED_SECRET_PREFIX to the prefix of the secrets Genesis may read, for example genesis/. The Outpost refuses every other secret name.
  3. Choose your store and give the Outpost’s own identity read access to it: The tokens capability still calls AWS when OUTPOST_SECRETS_SOURCE is azure or gcp. On EKS, the service account’s IRSA role must also cover those AWS calls. On a laptop, your own aws sso login, az login or gcloud auth application-default login session works.
  4. Restart the Outpost.
Secret names in Azure and Google. Key Vault and Secret Manager names cannot contain /, so the Outpost stores each / of a Genesis secret name as --: the reference outpost_acme-prod/genesis/postgres-prod#password reads the Key Vault secret (or Secret Manager secret, latest version) named genesis--postgres-prod. Otherwise use only letters, digits and - (Secret Manager also allows _); a name with other characters, or with -- itself, is refused. ALLOWED_SECRET_PREFIX stays in Genesis spelling (genesis/). Then use a secret reference on the connection; see Use a secret from the Outpost.

​
Rotate, revoke or remove

  • Rotate a Snowflake key without downtime. Register a new public key in the free slot (ALTER USER <user> SET RSA_PUBLIC_KEY_2 = '<new public key>'), restart the Outpost with the new private key, then ALTER USER <user> UNSET RSA_PUBLIC_KEY.
  • Rotate a Databricks secret. Add a second OAuth secret to the service principal, restart the Outpost with it, then delete the old secret.
  • Rotate or revoke the tunnel key. Choose New tunnel key for the Outpost and restart it with the new key. The old key stops working within about 15 seconds: Genesis ends that Outpost’s tunnel session (its log says its key was rotated or revoked). Other Outposts are not affected.
  • Revoke. Unset the user’s public keys or disable the user (ALTER USER <user> SET DISABLED = TRUE), or remove the service principal’s CAN USE. The Outpost’s next connection attempt is refused. A tunnel that is already open stays open until it reconnects; to cut it at once in Snowflake, also revoke the APP_OUTPOST_TUNNEL grant from the user’s role or restart the Genesis service.
  • Remove. Click Delete on the Outpost’s card. If saved connections choose it or reference one of its secrets, Genesis lists them and asks for a second confirmation; choose Delete anyway to proceed. Those connections stop working until you move them to another Outpost or update their secret references as needed. When you delete the last Outpost, Genesis also clears its remaining routes so hosts no longer map to a loopback address with no listener. Then stop the Outpost where it runs and drop its Snowflake user or Databricks service principal.