Setup

After installing the Gateway, this page covers configuration, security, verification, and monitoring.

Configuration

The Gateway is configured entirely via environment variables — no config files. The minimum to start is GATEWAY_PROVIDER plus the credentials that provider requires (see the Supported Providers table). Paper vs live is controlled by GATEWAY_MODE (default paper).

Server variables:

For the full list of per-provider env vars (ALPACA_*, BINANCE_*, OANDA_*, SAXO_*), see .env.example in the Gateway repo.

Securing the Gateway

The Gateway's API can place real-money orders. Before running it anywhere other than your own machine, secure it:

• Set GATEWAY_API_KEY. When set, every trading and data request must include the key as either Authorization: Bearer <key> or X-API-Key: <key>. Without it, anyone who can reach the port can trade with your broker account — the Gateway logs a warning at startup when running unauthenticated.
• Don't expose the port publicly. Keep the Gateway on a private network or behind a firewall; your strategy is usually the only client, often on the same host. The default bind address (GATEWAY_HOST=127.0.0.1) already restricts it to local connections.

The health probes (/livez, /readyz, /health) and /metrics stay unauthenticated even when GATEWAY_API_KEY is set, so orchestrators and scrapers keep working.

curl -H "X-API-Key: your-key" http://localhost:8080/v1/account

See Security and Authentication in the Gateway README for details.

Provider Selection

The Gateway serves exactly one provider per instance, chosen at startup by the GATEWAY_PROVIDER environment variable. The Gateway fails to start if GATEWAY_PROVIDER is unset.

Valid values and the credentials each requires are listed in the Supported Providers table. To switch providers, stop the Gateway, change GATEWAY_PROVIDER (and the relevant credential env vars), and restart — there is no runtime provider switching.

Feature-Gated Builds

When building from source, you can compile only the provider you need. This reduces binary size, compile time, and dependency surface:

# Build with only Alpaca support
cargo build --release --no-default-features --features alpaca

# Build with only Binance support
cargo build --release --no-default-features --features binance

# Combine multiple providers
cargo build --release --no-default-features --features alpaca,binance

# Build with all providers (default)
cargo build --release

Feature-gated builds are useful for production deployments where you only connect to a single provider.

Verifying the Gateway

After starting the Gateway, verify it is running correctly.

Health Check

The Gateway exposes three unauthenticated probes at the host root, intended for orchestrators and uptime checks:

# Liveness: is the process up?
curl -s http://localhost:8080/livez

# Detailed: are the configured providers connected?
curl -s http://localhost:8080/health

If /livez does not respond, the Gateway is not running or is on a different port. See the REST reference for the full probe response schemas.

REST API

Verify provider connectivity by querying your account:

curl http://localhost:8080/v1/account

This returns account information from your configured provider. If you see an authentication error, check your provider credentials.

WebSocket

Connect to the event stream to verify real-time data:

ws://localhost:8080/v1/ws

A successful connection receives market events from your provider.

For the full REST API schema, use the hosted openapi.json or run the Gateway with ENABLE_SWAGGER=true and browse /swagger-ui.

Monitoring

Prometheus Metrics

The Gateway exposes Prometheus-format metrics at /metrics on the same port as the REST API. These can be scraped by Prometheus, Grafana, Datadog, or any compatible monitoring tool.

Key metrics to watch:

• Order counts — submitted, filled, rejected, cancelled
• Latency — round-trip time from order submission to fill
• Connection status — WebSocket connection state to the provider
• Error rates — provider API errors, order rejections

Scraping Configuration

Add the Gateway to your Prometheus scrape targets:

scrape_configs:
  - job_name: 'trading-gateway'
    static_configs:
      - targets: ['localhost:8080']

Running on a Different Port

The Gateway listens on port 8080 by default. If another service already occupies it, set GATEWAY_PORT=9080 to change the listen port directly — this works for source builds and Docker alike. With Docker you can instead remap only the host side:

docker run -d \
  -p 9080:8080 \
  -e GATEWAY_PROVIDER=alpaca \
  -e GATEWAY_MODE=paper \
  -e ALPACA_API_KEY=your-key \
  -e ALPACA_API_SECRET=your-secret \
  ghcr.io/tektii/gateway:latest

Either way, connect your strategy to http://localhost:9080 (REST) and ws://localhost:9080/v1/ws (WebSocket). With the Docker remap the container still listens internally on 8080; only the host-side port changes.

Troubleshooting

Next Steps

• Going Live — Connect your backtested strategy to the Gateway for paper and live trading
• Trading API Concepts — Understand the unified protocol
• Connection Guide — Detailed WebSocket and REST connection patterns