Use Cases

Scenario: Fintech API with authenticated partner access

Illustrative scenario. The team, infrastructure, and timings below are example assumptions, not a customer case study.

Who: A small fintech team running a payment-processing API. Where: A single backend service on one virtual private server (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 Secure Ingress

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 containerized Node.js API listening on port 3000:

# Their existing API, nothing changes
node server.js  # listens on port 3000

2. Create a project and a service account in the Console

The team creates a project, a production environment, and a service account. The service account’s API key is the Warpgate token used in the next step.

3. Add Warpgate as a sidecar

# docker-compose.yml
services:
  api:
    build: .
    # No ports: the API is reachable only on the private Compose network

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

Warpgate connects outward to Secure Ingress and reaches the API over the private Compose network. The API is not published on the host, so the VPS needs no inbound port, no inbound firewall rule, and no public listener for it. The team also closes the direct path: the old public listener and the DNS record that pointed at the VPS are removed, so the only route to the API is through the Altuur Edge.

4. Configure routes in the Console

In the Secure Ingress Console, the team sets up:

5. 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 Altuur’s auth flow. The payment API receives pre-authenticated requests; no auth code in the application at all.

6. Go live

The API is now available at the production environment’s platform-provided hostname, for example https://payments-prod.mezusphere.io. Custom domains such as payments.example.com are on the roadmap. Traffic flows:

What they get

• TLS 1.3: automatic, no cert management
• Rate limiting and DDoS protection: per-edge abuse protection and broader DDoS mitigation built in at 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 for the API: the API is reachable only through Warpgate, as long as the host firewall stays closed to inbound traffic
• One platform: a single Secure Ingress configuration replaces separate Cloudflare, Auth0, API gateway, and certificate management setups

Time to deploy

In this scenario the change is one Compose file edit and a few Console settings. The team’s time goes into payment features, not infrastructure.

Scenario: Multi-region SaaS with staging environments

Illustrative scenario. The team, infrastructure, and timings below are example assumptions, not a customer case study.

Who: A B2B SaaS team 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 Secure Ingress

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 Secure Ingress

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: ["--api-key", "wg_prod_useast_...", "--upstream-url", "http://localhost:8080"]

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

2. Unified routing in the Console

All environments and regions are managed from one Console:

Each environment uses its platform-provided hostname. Custom domains such as app.example.com are on the roadmap. 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 for these services. Security groups become trivially simple once the old inbound rules are removed.
• DNS management: Secure Ingress handles edge routing on the platform-provided hostnames. Custom domains, one CNAME per endpoint, are on the roadmap.

The result

In this scenario, the ingress controller, cert-manager, and per-region OAuth configuration blocks leave the Kubernetes manifests. Adding a new region means deploying the service with a Warpgate sidecar and creating an environment in the Console, a small task instead of a multi-component infrastructure project.

Next steps

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