For the complete documentation index, see llms.txt. This page is also available as Markdown.

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

Deploying on Red Hat Enterprise Linux? Secure Gateway on RHEL with Podman covers RHEL hosts without Docker or Kubernetes, and Secure Gateway on MicroShift covers Red Hat Device Edge hosts running MicroShift. Both use dedicated installers with the same air-gapped bundle model.

Using Secure Gateway

On a machine with access to https://api.roboflow.com and https://repo.roboflow.com, 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 and a loopback-only HTTP listener for local testing or a TLS proxy on the same host:

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

Confirm it is running:

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:

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:

Connecting Inference Servers

Point each Inference Server at the gateway's HTTPS listener or TLS proxy with an explicit SECURE_GATEWAY URL. The server routes its Roboflow API calls and model downloads through that address.

Include the port when it differs from 443, such as https://gateway.example.com:8443. The certificate must cover the hostname or IP in the URL, and the Inference Server container must trust its issuing CA; configuring the gateway's outbound TLS_CA_BUNDLE does not install trust on clients.

Use the RHEL with Podman or MicroShift client installation instructions when using those deployments.

Legacy addresses and local tunnels

Use an explicit HTTPS scheme across versions. In the pending runtime-hardening build, bare addresses switch from HTTP to HTTPS, and plaintext remote or LAN gateways are rejected; see migration scope.

That build accepts explicit HTTP only for a loopback IP or localhost, such as SECURE_GATEWAY=http://127.0.0.1:8080. The tunnel must be reachable from the Inference Server's own network namespace; a bridge container's loopback is not its host's loopback.

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, with the same transport rules. Prefer SECURE_GATEWAY for new configurations.

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.

Last updated

Was this helpful?