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.
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, pull the Secure Gateway container:
docker pull repo.roboflow.com/roboflow-edge/secure-gateway:latestThe 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:latestConfirm 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?