Documentation
Welcome to the Mezusphere documentation. This is your starting point for understanding how Mezusphere works, deploying your first service, and managing your infrastructure through the Console.
Mezusphere unifies traffic ingress, authentication, authorization, and routing into a single software layer. Instead of configuring inbound traffic through layers of proxies and gateways, your workloads connect outward to Mezusphere through a lightweight sidecar called a Warpgate. End-user traffic enters through Mezusphere’s global edge, which handles TLS, authentication, caching, DDoS protection, and routing before forwarding requests to your Warpgate.
The result: deploying a secure, globally reachable internet service becomes a single repeatable pattern, regardless of cloud provider, language, or deployment platform.
Getting Started
You can go from zero to a globally reachable, authenticated service in four steps.
Step 1: Deploy your workload anywhere
Mezusphere is cloud-agnostic. Run your application on any cloud provider, in a container, on a virtual machine, or on your local development machine. Mezusphere does not require any specific runtime or deployment target.
Step 2: Add the Warpgate sidecar
Deploy the Warpgate alongside your workload. Warpgate connects outward to Mezusphere, so no inbound ports need to be opened on your infrastructure.
docker run mezusphere/warpgate \
--token YOUR_WARPGATE_TOKEN \
--upstream localhost:8080Step 3: Configure routes in the Console
Open the Console to set up your project. Define endpoints, configure URL path routing rules, set authentication requirements, and manage user access. The Console gives you full control over how traffic reaches your workload.
Step 4: Go live
Once configured, end users connect through Mezusphere’s global edge. Their traffic is authenticated, authorized, and routed to your Warpgate automatically. Your service is globally reachable and secured without any changes to your application code.
Core Concepts
Organizations
The top-level entity in Mezusphere. An organization groups projects, billing, and team access. Everything in Mezusphere belongs to an organization.
Projects
A logical grouping of environments, routes, Warpgates, and service accounts under an organization. Projects represent a single service or application that you want to expose through Mezusphere.
Environments
Named deployment targets within a project, such as Development, Staging, and Production. Each environment has its own endpoint URL and can be independently enabled or disabled.
Routes
URL path routing rules within a project. Routes determine how incoming requests are directed to your workload. Mezusphere supports three matching modes:
- Prefix: matches any path starting with the specified value
- Exact: matches the path exactly
- Regexp: matches using a regular expression
Routes can require authentication and specific permissions. CORS configuration is also supported per route.
Warpgates
Lightweight sidecars deployed alongside your workloads. Warpgates register themselves with the control plane using service account credentials. They report their status (connected, disconnected, or unknown) and IP address. Warpgates cannot be created through the Console; they register themselves automatically when deployed.
Service Accounts
Machine credentials used for Warpgate registration and API access. Each service account has an API key and configurable permissions. Service accounts are scoped to a project.
User Directories
Collections of end-user accounts, scoped to a project or organization. User directories let you manage separate pools of users for different services or for your entire organization.
User Accounts
End users who access services through Mezusphere. User accounts have a status (active, inactive, or suspended), login tracking, and profile information including name, email, and display name.
Warpgate
Warpgate is the lightweight sidecar agent that connects your workload to Mezusphere. It implements an inverted ingress model: instead of opening inbound ports and configuring firewalls, Warpgate connects outward to Mezusphere’s global edge.
Deployment Options
Warpgate can be deployed in several ways:
- Docker: run as a container alongside your application
- Binary: download and run the standalone binary
- Kubernetes: deploy as a sidecar container in your pod
How It Connects
Warpgate initiates an outbound connection to Mezusphere’s global edge. This means your infrastructure requires no inbound ports, no firewall rules, and no VPN configuration. Warpgate authenticates itself using a service account API key and maintains a persistent connection for receiving traffic.
Cloud-Agnostic
Warpgate works the same way regardless of where your workload runs: AWS, GCP, Azure, on-premises data centers, or your local development machine.
Console
The Console is Mezusphere’s web-based management UI. It provides a central interface for configuring and monitoring all aspects of your Mezusphere deployment.
Key Workflows
- Create projects: set up new services under your organization
- Configure routes: define URL path routing rules with authentication requirements
- Enable authentication: require end-user login and set permission-based access controls
- Manage users: create and manage user directories and user accounts
- Manage environments: configure deployment targets with endpoint URLs
- Manage service accounts: create credentials for Warpgate registration
- View metrics: monitor traffic, authentication outcomes, and system status
Use Cases
See real-world deployment scenarios showing how teams use Mezusphere to replace multi-vendor infrastructure stacks:
- Fintech API: A three-person startup secures partner API access with auth, DDoS protection, and TLS in under 30 minutes
- Multi-region SaaS: A 15-person team unifies routing, auth, and TLS across AWS and GCP with one Console
Read the full walkthroughs in Use Cases.
Security
Mezusphere treats security as architecture, not configuration. The outbound-only connectivity model produces structural security guarantees:
- TLS 1.3 everywhere: all traffic is encrypted, including mutual TLS (mTLS) between Warpgates and edge nodes
- Zero public attack surface: no open ports, no public IPs, no discoverable origin
- Edge-enforced authentication: auth is applied before traffic reaches your Warpgate
- Defense in depth: security policies enforced at the edge and validated again at the Warpgate
Read the full Security documentation for details on transport security, the authentication model, and data protection.