Deploy a gateway

The Sentinel gateway is a containerized, lightweight security proxy designed to run closest to your applications.

To register with the SUPERWISE® control plane, a gateway needs a valid SUPERWISE® API Client ID and Secret (how to generate credentials). Every deployment method below requires them.

Register a reachable endpoint

When a gateway starts, it tells the SUPERWISE® control plane the URL where it can be reached. Teammates then see that URL in the app: on the gateway's page, the Connect button (available once the gateway is Active) shows ready-to-copy snippets pointing at it.

Control the registered URL with the optional SENTINEL_EXTERNAL_HOST environment variable. Set it on the gateway — -e SENTINEL_EXTERNAL_HOST=https://sentinel.yourcompany.com for Docker, or as a gateway-server.env entry for Helm (see the Helm example below):

• Set it explicitly when the gateway sits behind a load balancer, API gateway, or ingress. Register the public endpoint so others connect through the right address — not the container's internal one.
• Leave it unset for local or single-host testing. The gateway auto-detects its local IPv4 and registers http://<ip> (no port). That's fine locally, but it won't be reachable from other machines — set the variable for anything shared.

You can also edit the Gateway URL at any time from the app's Connect dialog.

Architecture lifecycle & states

Once deployed, the gateway continuously communicates with the control plane to report its status and pull configuration updates.

• Pending → Active: A newly deployed gateway starts in Pending. Once the control plane receives its first heartbeat, the gateway becomes Active.

• Heartbeats: The gateway sends a heartbeat every 60 seconds. If an Active gateway misses heartbeats for 10 minutes (10 consecutive), it drops back to Pending.

  

Deployment options

Option 1: Plain Docker

For stand-alone machines, testing, or isolated server instances, you can run Sentinel directly via Docker. Because the underlying image binaries vary, make sure to pick the command corresponding to your target platform hardware architecture (e.g., Linux x86 vs. Apple Silicon).

Docker run

The Sentinel image is published for linux/amd64. The --platform linux/amd64 flag is required on Apple Silicon Macs (M1/M2/M3) and is harmless on native amd64 hosts.

docker run --platform linux/amd64 \
  --name sentinel \
  -p 8000:8000 \
  -e SENTINEL_ID=$SENTINEL_ID \
  -e SW_CLIENT_ID=$SW_CLIENT_ID \
  -e SW_CLIENT_SECRET=$SW_CLIENT_SECRET \
  us-central1-docker.pkg.dev/admina33d6818/sentinel-public/sentinel:latest

docker run --platform linux/amd64 `
  --name sentinel `
  -p 8000:8000 `
  -e SENTINEL_ID=$env:SENTINEL_ID `
  -e SW_CLIENT_ID=$env:SW_CLIENT_ID `
  -e SW_CLIENT_SECRET=$env:SW_CLIENT_SECRET `
  us-central1-docker.pkg.dev/admina33d6818/sentinel-public/sentinel:latest

Option 2: The Sentinel CLI (local deployments only)

The sentinel command-line tool provides a simplified developer workflow to provision and toggle local gateways only.

To manage your gateway status, use the native start/stop commands:

sentinel gateway start
sentinel gateway stop

State matching intelligence

• Explicit provisioning: When running sentinel gateway start (or executing a clean quickstart), you can supply a specific --sentinel-id parameter directly to fetch a designated cloud profile configuration.
• Smart fallback: The CLI automatically reads your local state files. If it detects a previously configured profile, it will intelligently prompt or suggest resuming that exact local container configuration instead of creating a new Sentinel.

🛠️ Under the hood: The CLI manages and persists its tracking state, provider configurations, and assigned gateway parameters locally inside a state file located at ~/.config/sentinel/config.json.

Option 3: Helm (production-scale Kubernetes)

For enterprise-grade production environments requiring horizontal scaling, high availability, and native monitoring, SUPERWISE® provides a managed Helm chart. This enables seamless provisioning directly inside your existing Kubernetes clusters.

helm upgrade --install sentinel-customers \
  oci://us-central1-docker.pkg.dev/admina33d6818/sentinel-public/sentinel-customers \
  --set global.imageRegistry=us-central1-docker.pkg.dev/admina33d6818/sentinel-public \
  --set gateway-server.image.repository=sentinel \
  --set gateway-server.image.tag=latest \
  --set "gateway-server.env[0].name=SENTINEL_ID,gateway-server.env[0].value=$SENTINEL_ID" \
  --set "gateway-server.env[1].name=SW_CLIENT_ID,gateway-server.env[1].value=$SW_CLIENT_ID" \
  --set "gateway-server.env[2].name=SW_CLIENT_SECRET,gateway-server.env[2].value=$SW_CLIENT_SECRET" \
  --set "gateway-server.env[3].name=SENTINEL_EXTERNAL_HOST,gateway-server.env[3].value=$SENTINEL_EXTERNAL_HOST"

The last line is optional — omit it to let the gateway auto-detect its address. Because Helm replaces the whole gateway-server.env list when you set entries with --set, keep the credential entries alongside it as shown.

Next steps

• Point your applications at the gateway: Connect your applications
• Proxy a self-hosted or alternative model: Custom providers