Why We Built Mezusphere

Every cloud architecture diagram I’ve ever seen looks the same.

Load balancer, reverse proxy, API gateway, CDN, WAF, auth provider, DDoS protection, all wired together with YAML and prayers. Ten services, six vendors, three billing models. And before anyone writes a single line of business logic, they spend weeks configuring the same boilerplate that every other company configures the same way.

I saw this pattern repeat at every company I worked at, in every cloud, in every country.

The 80% problem

About 80% of a typical cloud architecture is non-differentiating infrastructure. It doesn’t make your product better. It doesn’t give you a competitive advantage. It’s just the table stakes you have to set up before you can serve a single request.

For startups, this is devastating. You don’t have DevOps engineers. You don’t have security specialists. You can’t afford to spend your first month configuring infrastructure instead of building your product. But the alternative, skipping security, using basic auth, hoping you don’t get DDoS’d, is worse.

For growing companies, it’s a different kind of pain. You’ve got the infrastructure running, but now you’re maintaining it. Every new service needs the same setup. Every auth integration is a multi-week project. Every vendor bill is a surprise. Your engineers spend more time on infrastructure than on features.

The identity question

At Authlete, where I spent three years leading engineering, I saw the authentication problem up close. OAuth, OpenID Connect, token management: these are genuinely hard problems. But even when you solve them well, you still need to wire the solution into your traffic layer. Token validation happens in your application code, not at the edge. Auth errors cascade into routing errors. The identity system and the traffic system are separate, and the gap between them is where security vulnerabilities live.

That’s when the idea crystallized: what if authentication wasn’t a separate system to integrate? What if it was a property of the traffic layer itself? What if every request, human, device, service, or AI agent, was authenticated at the edge before it ever reached your workload?

The inverted ingress model

The architecture that emerged was counterintuitive. Instead of configuring inbound traffic through layers of proxies and gateways, the workload connects outward to the edge. A lightweight sidecar, we call it a Warpgate, establishes a secure outbound tunnel. End-user traffic enters through the edge, where TLS, auth, DDoS protection, and routing are handled automatically, and is forwarded to the Warpgate.

No inbound ports. No firewall rules. No reverse proxies. No API gateways. The entire inbound networking layer simply doesn’t exist.

This isn’t just simpler to set up; it’s structurally more secure. Your workload has no public attack surface. There are no ports to scan, no origins to discover, no load balancers to misconfigure. The attack surface is Mezusphere’s global edge, which is purpose-built to handle it.

Japan-born, globally competitive

There is no made-in-Japan cloud platform that has achieved true global success. We intend to change that.

The name Mezusphere comes from Japanese 珍しい (mezurashii), rare, distinctive, combined with sphere, a bounded domain. Something uncommon and deliberate, not mass-produced.

We built Mezusphere because we believe the infrastructure layer between your code and your users should be one thing, not ten. Because security and performance are primitives, not add-ons. And because complexity is the hidden tax on growth.