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.
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, and routing, stays in the edge, while your workload stays behind the outbound connector.
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 \
--api-key YOUR_API_KEY \
--upstream-url localhost:8080That's it. Your workload is now reachable through Mezusphere's global edge with automatic TLS, DNS, 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: ["--api-key", "YOUR_API_KEY",
"--upstream-url", "app:8080"]
depends_on:
- appEcho mode: try it with no upstream
Run Warpgate with --echo and it answers every request through your endpoint with a JSON reflection of what your service would receive: method, path, headers, identity.
docker run mezusphere/warpgate \
--api-key YOUR_API_KEY \
--echoWhen the response comes back through your endpoint, replace --echo with --upstream-url and ship.
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:
- "--api-key"
- "YOUR_API_KEY"
- "--upstream-url"
- "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. Its bootstrapped identity is persisted, so restarts reconnect in seconds, and a single Warpgate holds tunnels to multiple edge nodes at once for redundancy.
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. The container image is about 5 MB, built from scratch with no shell and no dependencies, and runs as a non-root user. 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 |
Where the traditional stack is still ahead: mature tooling ecosystems, decades of documentation, and communities that have seen every failure mode. Warpgate trades that familiarity for a smaller surface: one artifact, no inbound exposure, and configuration that lives in one control plane.
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, and routing are handled by the platform. See how it all comes together in the Console, or contact hello@mezusphere.com to learn more.