Use Cases

Scenario: Fintech API with authenticated partner access

Who: A three-person fintech startup running a payment-processing API. Where: A single backend service on a $40/month VPS. Problem: They need TLS, DDoS protection, and authenticated API access for merchant partners, but they don’t have a DevOps engineer and can’t spend weeks wiring together Cloudflare, Auth0, and an API gateway.

Before Mezusphere

Their deployment requires configuring and maintaining multiple services:

Five vendors, five configurations, five potential points of failure, replaced by one.

Step-by-step deployment

1. Start with the existing API

The team already has a Node.js API listening on port 3000:

# Their existing setup — nothing changes
node server.js  # listens on localhost:3000

2. Add Warpgate as a sidecar

# docker-compose.yml
services:
  api:
    build: .
    ports:
      - "3000:3000"

  warpgate:
    image: mezusphere/warpgate
    command: ["--token", "wg_prod_abc123...", "--upstream", "api:3000"]
    depends_on:
      - api

Warpgate connects outward to Mezusphere. No inbound ports, no firewall rules, no public IP required on the VPS.

3. Configure routes in the Console

In the Mezusphere Console, the team sets up:

4. Enable partner authentication

For the /api/v1/* routes, the team enables authentication in the Console:

• Create a User Directory called “Merchant Partners”
• Add partner accounts with email + password credentials
• Set the /api/v1/* route to require authentication

Partners receive login credentials and get access tokens through Mezusphere’s auth flow. The payment API receives pre-authenticated requests; no auth code in the application at all.

5. Go live

The API is now available at https://payments.example.com. Traffic flows:

What they get

• TLS 1.3: automatic, no cert management
• DDoS protection: built into the edge, no configuration
• Partner authentication: managed in the Console, zero application code
• Path-based routing: public health checks and authenticated API on the same domain
• No inbound ports: the VPS has no public-facing ports at all
• One bill: a single Mezusphere subscription replaces separate Cloudflare, Auth0, API gateway, and cert management costs

Total time to deploy: under 30 minutes

The team spends their time building payment features, not managing infrastructure.

Scenario: Multi-region SaaS with staging environments

Who: A 15-person B2B SaaS company with a React frontend and three backend microservices. Where: Services spread across AWS (us-east-1) and GCP (asia-northeast1) for latency. Problem: Managing separate Cloudflare configs, nginx ingress controllers, and OAuth integrations per region and per environment (dev, staging, prod) creates a configuration matrix that’s hard to maintain.

Before Mezusphere

Each environment × region combination requires its own:

• Ingress controller configuration
• TLS certificate management
• OAuth client credentials
• Firewall / security group rules
• DNS records

That’s 6+ configurations to keep in sync (2 regions × 3 environments), each with different credentials and slightly different setups.

With Mezusphere

1. Deploy Warpgates per service, per environment

Each microservice gets a Warpgate sidecar with a per-environment token:

# Kubernetes sidecar (production, us-east-1)
- name: warpgate
  image: mezusphere/warpgate
  args: ["--token", "wg_prod_useast_...", "--upstream", "localhost:8080"]

# Kubernetes sidecar (staging, asia-northeast1)
- name: warpgate
  image: mezusphere/warpgate
  args: ["--token", "wg_staging_apne1_...", "--upstream", "localhost:8080"]

2. Unified routing in the Console

All environments and regions are managed from one Console:

Routes, auth rules, and permissions are configured once and applied consistently across regions.

3. What changes

• Ingress controllers: removed. Warpgate replaces them.
• TLS certs: automatic. No cert-manager, no Let’s Encrypt cron jobs.
• OAuth per environment: one auth configuration in the Console, not separate OAuth clients per region.
• Firewall rules: no inbound ports needed anywhere. Security groups become trivially simple.
• DNS management: Mezusphere handles edge routing. One CNAME per endpoint.

The result

The infrastructure team’s Kubernetes manifests shrink by hundreds of lines. Adding a new region means deploying the service with a Warpgate sidecar and creating an environment in the Console, a 10-minute task instead of a multi-day infrastructure project.

Next steps

• Getting Started: Deploy your first service with Warpgate
• Core Concepts: Understand organizations, projects, environments, and routes