Warpgate

Warpgate is the lightweight sidecar agent that connects your workload to Mezusphere. It implements the inverted ingress model: instead of opening inbound ports and configuring firewalls, Warpgate connects outward to Mezusphere’s global edge.

How it works

1. Warpgate starts alongside your workload
2. It initiates an outbound TLS 1.3 connection to Mezusphere’s global edge
3. It authenticates using a service account API key
4. Mezusphere forwards end-user traffic through this established tunnel
5. Warpgate passes the traffic to your workload on localhost

Your workload never accepts inbound connections from the internet. There are no open ports, no firewall rules, and no public IP addresses required.

Deployment options

Docker

Run Warpgate as a container alongside your application:

docker run mezusphere/warpgate \
  --api-key YOUR_API_KEY \
  --upstream-url localhost:8080

Or add it to your docker-compose.yml:

services:
  app:
    image: your-app:latest
    ports:
      - "8080:8080"

  warpgate:
    image: mezusphere/warpgate
    command: ["--api-key", "YOUR_API_KEY", "--upstream-url", "app:8080"]
    depends_on:
      - app

Echo mode

Verify connectivity before wiring an upstream. With --echo, Warpgate answers every request through your endpoint with a JSON reflection of the request it received: method, path, headers, and identity.

docker run mezusphere/warpgate --api-key YOUR_API_KEY --echo

When the echo response comes back through your endpoint, replace --echo with --upstream-url and point it at your service.

The mezusphere/warpgate image is multi-arch (linux/amd64, linux/arm64) and runs anywhere Docker or Kubernetes runs, including arm64 edge devices.

Kubernetes

Deploy Warpgate as a sidecar container in your pod:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-service
spec:
  template:
    spec:
      containers:
        - name: app
          image: your-app:latest
          ports:
            - containerPort: 8080
        - name: warpgate
          image: mezusphere/warpgate
          args:
            - "--api-key"
            - "YOUR_API_KEY"
            - "--upstream-url"
            - "localhost:8080"

Works with any Kubernetes distribution: EKS, GKE, AKS, k3s, or self-managed clusters.

Configuration

Command-line flags

Environment variables

Every flag can also be set via an environment variable: the flag name in uppercase with underscores, no prefix.

Connectivity

Outbound connection

Warpgate establishes a persistent outbound connection to Mezusphere’s global edge using TLS 1.3 with mutual authentication (mTLS). The connection is:

• Encrypted: TLS 1.3, no downgrade
• Authenticated: mutual TLS with service account credentials
• Persistent: maintained for the lifetime of the Warpgate process
• Reconnecting: automatic reconnection with backoff on network interruption

Network requirements

Warpgate requires only outbound HTTPS connectivity. No inbound ports, no firewall rules, no VPN configuration needed.

Cloud-agnostic

Warpgate works identically regardless of where your workload runs:

• AWS (EC2, ECS, EKS, Lambda)
• Google Cloud (GCE, GKE, Cloud Run)
• Azure (VMs, AKS, Container Instances)
• On-premises data centers
• Local development machines
• Edge devices (Raspberry Pi, IoT)

The deployment pattern is always the same: run Warpgate alongside your workload, provide a token, point it at your upstream.

Resource usage

Warpgate is designed to be lightweight:

• Single static binary
• Minimal memory footprint
• Negligible CPU overhead
• No disk I/O beyond logging

It is not a proxy, not a service mesh control plane, and not an agent that phones home with telemetry. Its only connections are the outbound tunnels and control-plane session described above.

For your own monitoring, Warpgate can expose a local Prometheus /metrics endpoint with standard reverse-proxy metrics: request rate, latency, sizes, upstream health, and tunnel reconnects. It is off by default (enable with --metrics-addr), and nothing is reported back to Mezusphere.