Warpgate. Your workload's connection to the world.

Warpgate is the only Mezusphere component you deploy. A single lightweight container that runs next to your workload and connects it outward to Mezusphere's global edge, replacing firewalls, reverse proxies, load balancers, and API gateways with one repeatable and scalable pattern.

What Warpgate is

Warpgate is a lightweight software connector that runs next to your workload and connects it outward to Mezusphere. Think of it as:

A sidecar for internet connectivity

Warpgate sits alongside your workload and handles the connection to the outside world. Your application code does not need to know about proxies, TLS, or ingress configuration.

A forwarding agent for approved traffic

Warpgate only accepts traffic that has already been authenticated, authorized, and routed by Mezusphere's global edge. It forwards approved requests to the local upstream workload.

The component that makes inverted ingress real

Instead of building an inbound stack, you deploy Warpgate. It connects outward. The public-facing logic stays in Mezusphere's edge. Your workload stays behind the outbound connector.

Your Infrastructure

Your Workload

:8080

localhost

Warpgate

Outbound-only mTLS Auto-reconnect

No inbound ports · No firewall rules · No public IP

Outbound TLS 1.3

Mezusphere Edge

TLSAuthDDoSRouting

HTTPS

End Users

Why Warpgate exists

In a traditional deployment, publishing a service to the internet requires building an inbound stack: open ports, add firewall rules, configure a load balancer, terminate TLS, add API gateway behavior, integrate auth, add DDoS and WAF controls. Every layer adds complexity, cost, and attack surface.

Warpgate eliminates most of that work. Instead of building an inbound stack, you deploy Warpgate next to your workload. Warpgate connects outward to Mezusphere. The public-facing logic, including TLS termination, authentication, DDoS protection, and routing, stays in the edge, while your workload stays behind the outbound connector.

Your Workload

Warpgate

Outbound TLS 1.3

Mezusphere Edge

TLSAuthDDoSRouting

HTTPS

End Users

How Warpgate works

The lifecycle of a Warpgate instance is straightforward:

1. Authenticate

Warpgate starts beside your workload and authenticates itself to the control plane using a service account credential. It receives its environment and route configuration.

2. Connect

Warpgate establishes secure outbound tunnel connections to one or more edge nodes using TLS 1.3 with mutual authentication (mTLS). No inbound ports needed.

3. Forward

Mezusphere's global edge sends approved traffic through the tunnel. Warpgate forwards it to the local upstream workload and returns the response back through the tunnel.

Once connected, Warpgate stays running: heartbeating, reconnecting automatically on network interruption, and watching for configuration updates from the control plane. There is no manual intervention required after initial deployment.

Deploy anywhere

Warpgate works alongside any workload on any cloud, VM, or bare metal. The deployment pattern is always the same: run Warpgate next to your workload, provide a token, point it at your upstream.

Get started in one command

docker run mezusphere/warpgate \
  --token YOUR_WARPGATE_TOKEN \
  --upstream localhost:8080

That's it. Your workload is now reachable through Mezusphere's global edge with automatic TLS, DNS, DDoS protection, and authentication, all configured from the Console.

Docker sidecar

Add Warpgate to your docker-compose.yml or run it alongside your container. Ideal for local development and single-container deployments.

services:
  app:
    image: your-app:latest
    ports:
      - "8080:8080"
  warpgate:
    image: mezusphere/warpgate
    command: ["--token", "YOUR_WARPGATE_TOKEN",
              "--upstream", "app:8080"]
    depends_on:
      - app

Standalone binary

Download the Warpgate binary for Linux, macOS, or Windows. Run it as a systemd service, a launchd agent, or from the command line.

# Download
curl -fsSL https://get.mezusphere.com/warpgate | sh

# Run directly
warpgate --token YOUR_WARPGATE_TOKEN \
  --upstream localhost:8080

# Or install as a systemd service
sudo warpgate install \
  --token YOUR_WARPGATE_TOKEN \
  --upstream localhost:8080
sudo systemctl start warpgate

Kubernetes

Deploy Warpgate as a sidecar container in your pod spec. Works with EKS, GKE, AKS, k3s, or self-managed clusters.

spec:
  containers:
    - name: app
      image: your-app:latest
      ports:
        - containerPort: 8080
    - name: warpgate
      image: mezusphere/warpgate
      args:
        - "--token"
        - "YOUR_WARPGATE_TOKEN"
        - "--upstream"
        - "localhost:8080"

Production-grade operational behavior

Warpgate is in the critical path of your production traffic. It is not a toy tunnel. It includes the operational behaviors production systems require:

Reliability

Automatic registration and reconnection

Warpgate registers itself with the control plane on startup, heartbeats continuously, and reconnects independently with exponential backoff on network interruption. Graceful deregistration on shutdown.

Configuration

Real-time config updates

Warpgate watches for configuration changes from the control plane and applies them without restart. Route changes, policy updates, and environment adjustments take effect automatically.

Security

Defense in depth

Warpgate validates routes as a defense-in-depth measure, forwards identity and request metadata, and enforces response size limits to protect memory. All connections are encrypted with TLS 1.3.

Health

Upstream health checks

Optional health checking ensures Warpgate only forwards traffic to a healthy upstream workload. Configurable health path and timeout settings.

Footprint

Minimal resource usage

A single static binary with minimal memory footprint and negligible CPU overhead. No disk I/O beyond logging. Warpgate adds near-zero overhead to your workload.

Network

Outbound-only connectivity

Warpgate requires only outbound HTTPS on port 443. No inbound ports, no firewall rules, no VPN configuration. Works behind NAT, in private subnets, and in restricted network environments.

What Warpgate replaces

Warpgate collapses multiple architectural jobs into one deployable artifact.

Capability	Traditional stack	With Warpgate
Internet connectivity	Public IPs, firewall rules, reverse proxy	Outbound tunnel, automatic
Service registration	DNS records, load balancer targets, health checks	Auto-registers with control plane
Secure forwarding	mTLS setup, proxy config, cert rotation	Built into the tunnel: TLS 1.3 + mTLS
Route-aware delivery	NGINX rules, Traefik routers, Kong routes	Edge-enforced, no local config
Platform presence	Custom integration code per service	One token, one upstream, done

Your workflow

Deploying with Warpgate takes six steps:

1. Create a project

Open the Console, create a project and environment for your service.

2. Get a token

Create a service account and obtain the Warpgate token.

3. Run your workload

Start your application wherever it runs, on any cloud, any platform.

4. Deploy Warpgate

Run Warpgate next to your workload with the token and upstream address.

5. Configure routes

Define routes, authentication rules, and policies in the Console.

6. Go live

Your service is globally reachable, authenticated, and secured. Watch status in the Console.

One connector. Zero infrastructure boilerplate.

Deploy your code, add a Warpgate. TLS, DNS, auth, WAF, DDoS protection, and routing are handled by the platform. See how it all comes together in the Console, or contact hello@mezusphere.com to learn more.