Secure Gateway

Secure Gateway proxies the routes Roboflow Deployment servers need into your company's DMZ, and caches model weights and container images locally.

Secure Gateway is a proxy for the Roboflow API and your models' weights, for when you firewall the Roboflow Inference Server from the internet. It is the successor to the License Server and adds local caching of model weights and container images, so a fleet of inference servers shares one controlled point of egress.

This page covers the essentials. For the complete configuration and operations reference, see the Secure Gateway manual.

Prerequisites

• Docker Engine 20.10+, or Kubernetes v1.24+

• A host with access to api.roboflow.com and repo.roboflow.com

• Port 80 available, with TLS terminated at a load balancer in front of the gateway or inside the container

• 4GB+ memory

• An S3 bucket, or 50GB+ of local disk for the cache

Using Secure Gateway

On a machine with access to https://api.roboflow.com and https://repo.roboflow.com (and port 80 open to the Inference Server running in your private network), pull the Secure Gateway container:

docker pull repo.roboflow.com/roboflow-edge/secure-gateway:latest

The latest tag tracks the most recent release. For production, and especially for air-gapped deployments, pin a specific version instead so upgrades stay deliberate and reproducible, for example repo.roboflow.com/roboflow-edge/secure-gateway:0.2.0.

Run it with a local disk cache:

docker run -d --name secure-gateway -p 80:80 --restart unless-stopped \
    -v gateway-cache:/var/cache/secure-gateway \
    repo.roboflow.com/roboflow-edge/secure-gateway:latest

Confirm it is running:

curl http://localhost/health

To cache on S3 instead of local disk, set the CACHE_S3_BUCKET and CACHE_S3_REGION environment variables. Leave the credentials unset to use an instance or IAM role.

TLS certificates

By default the gateway listens on plain HTTP, and you terminate TLS at a load balancer in front of it. To serve HTTPS from the gateway itself, mount your certificate and private key into the container and set both TLS_CERT_FILE and TLS_KEY_FILE. The gateway then serves HTTPS on its configured port:

docker run -d --name secure-gateway -p 443:443 --restart unless-stopped \
    -e PORT=443 \
    -e TLS_CERT_FILE=/etc/ssl/certs/gateway.crt \
    -e TLS_KEY_FILE=/etc/ssl/private/gateway.key \
    -v /path/to/certs:/etc/ssl:ro \
    -v gateway-cache:/var/cache/secure-gateway \
    repo.roboflow.com/roboflow-edge/secure-gateway:latest

Both TLS_CERT_FILE and TLS_KEY_FILE are required to enable inbound HTTPS, and each points to a PEM-encoded file.

When the gateway's outbound traffic passes through a corporate TLS inspection proxy, such as Zscaler, set TLS_CA_BUNDLE to that proxy's CA bundle so the gateway trusts its connections to api.roboflow.com and repo.roboflow.com:

-e TLS_CA_BUNDLE=/etc/ssl/certs/corporate-ca.pem

Connecting Inference Servers

Point each Inference Server at the gateway with the SECURE_GATEWAY environment variable. Set it to the gateway's hostname or IP address, with no scheme. The Inference Server then routes its Roboflow API calls and model weight downloads through the gateway instead of reaching the internet directly.

sudo docker run --net=host \
    --env SECURE_GATEWAY=10.0.1.1 \
    roboflow/inference-server:cpu

If the gateway listens on a port other than 80, include it, for example SECURE_GATEWAY=10.0.1.1:8080. The Inference Server connects to the gateway over HTTP at this address, so confirm the host and port are reachable from the Inference Server's network.

Only the gateway needs outbound access to api.roboflow.com and repo.roboflow.com. After the Inference Server starts, run a model and confirm the requests appear in the gateway's access logs.

The legacy LICENSE_SERVER variable is still accepted as an alias for SECURE_GATEWAY, so existing deployments keep working. It is deprecated and scheduled for removal at the end of Q3 2026.

Caching

Secure Gateway caches each response on first download, tiered by how often the content changes. Content-addressed container blobs and model weights are held longest, and mutable API responses for a shorter window. Subsequent requests from any Inference Server are served from the cache, which reduces bandwidth use and cold starts across a fleet.