Architecture
Every request to your service crosses three layers on the way in. Each layer does one job, and the boundaries between them are the platform's whole reason for existing.
Edge
Cloudflare
DDoS protection · WAF · TLS
ComputeSphere gateway
N instances of your service
The three layers
| Layer | What's here | What you don't manage |
|---|---|---|
| Edge | Cloudflare absorbs volumetric attacks, the WAF inspects every request, TLS terminates at version 1.2 or above. Auto-generated URLs are Cloudflare-fronted from day one; custom domains pick up the same protection the moment their certificate issues. | DDoS posture, WAF rules, TLS termination, certificate issuance and renewal. |
| ComputeSphere gateway | The door to your service. Routes the request to a healthy spherelet, applies your service's networking config, hands it off. | Load balancing, health-gating, internal mTLS between gateway and spherelets. |
| Your spherelets | Your code, running. New spherelets only join the rotation after passing a health check; failing ones leave automatically. | Spherelet scheduling, restarts, capacity tracking against your account. |
Three boundaries, one direction. The customer never reaches your spherelet by accident, and your spherelet never sees a request that hasn't been triaged by the edge.
Regions
You choose a region when you create an environment, and every service in that environment runs there. The console shows the regions open to your account when you create one.
Multi-region. Running a single service across regions isn't supported yet — every spherelet in a service lives in one region. If a region has a major incident, services in that region are affected. Multi-region failover is on the roadmap; until then, two-spherelet HA inside a region is the strongest reliability primitive available (see Reliability).
Data plane and control plane
The two planes are decoupled on purpose. The path above — edge → gateway → spherelet — is the data plane. The API, console, and build system are the control plane. They share no critical dependencies.
| Data plane | Control plane | |
|---|---|---|
| Job | Serve traffic to your running services. | Let you change services — deploy, scale, configure. |
| What it runs | Edge, gateway, your spherelets. | The ComputeSphere API, web console, build pipelines, billing. |
| If it's degraded | Your service is unreachable or slow. | You can't deploy or change anything; running services keep serving. |
| Status page | Tracked separately. | Tracked separately. |
A control plane incident means you can't deploy. It does not mean your services stop. That separation is the practical reason a maintenance window on the API doesn't take production down with it.
Honest limits
- No cross-region failover. Each environment runs in the one region you pick; a regional outage takes services in that region with it. Track status.computesphere.com and lean on in-region multi-spherelet HA.
- No private edge networks. Everything terminates at the public edge first. If you need a private link from your network to your services, contact us — it's not a self-service product yet.
- Egress isn't shaped per region. Outbound traffic from your spherelets exits via the platform's default route. You can't pin egress IPs or route through your own VPC today.
- Region is chosen per environment. You pick the region when you create an environment, so one account can run environments in different regions. Moving an existing environment to another region isn't self-service — open a support request and we'll work through it.
What's next
- Reliability — how zero-downtime deploys, health checks, and multi-spherelet HA keep traffic flowing during change.
- Security — what's enforced at each layer above, and what your service is responsible for.
- Maintenance — how platform updates roll without scheduled downtime.
- SLA — the operational targets behind the boundaries on this page.