DDoS protection
Every ComputeSphere service is shielded from DDoS attacks the moment it has a deployment. No configuration. No upcharge. No tier gate. A Hobby project gets the same edge protection as an Enterprise contract.
The protection runs at the edge — packets that look like an attack are absorbed before they reach the ComputeSphere gateway, let alone your spherelets. Your code only sees traffic that's been triaged.
What's absorbed at the edge
| Layer | What it absorbs |
|---|---|
| L3 / L4 — Volumetric | Packet floods, UDP / ICMP amplification, reflection attacks. Capacity is provider-scale, not customer-scale. |
| L3 / L4 — Protocol | SYN floods, ACK floods, malformed-packet attacks. Stopped at the network layer before TLS even begins. |
| L7 — Application | HTTP floods, slow-loris-style connection holds, malicious bot patterns. Filtered by the edge WAF and bot management. |
| TLS | Terminated at the edge (TLS 1.2 minimum). Your service only sees decrypted, inspected requests. |
Which traffic paths are covered
| Surface | Protected? | How |
|---|---|---|
Auto-generated service URL (silver-cobra.computesphere.app) | ✓ | Edge-fronted from the first deploy. |
| Custom domains attached through the console | ✓ | Protection activates the moment the certificate issues. |
| Direct infrastructure / origin access | — | Origins aren't publicly exposed. All inbound traffic enters through the ComputeSphere edge. |
Shared responsibility
| Platform handles | You handle | |
|---|---|---|
| Volumetric floods | Absorbed at the edge | — |
| Protocol-level attacks | Absorbed at the edge | — |
| Generic L7 attacks (HTTP flood, bot patterns) | Edge WAF + bot management | — |
| Application-specific abuse | — | Rate-limit your login / signup / checkout endpoints; throttle expensive query patterns; cap user-bound operations |
| Credential stuffing on your auth | — | Lockouts, CAPTCHAs, exponential backoff, monitoring for hit patterns |
| Capacity to absorb a burst | — | Auto-scale within your account capacity; right-size your spherelet shape |
The edge handles attacks that look like attacks. Application-layer abuse that looks like real traffic (one user, one TCP connection, one valid login attempt at a time) is yours to model in your service.
During an active attack
If you suspect your service is being targeted:
- Check status.computesphere.com for a platform-wide incident. Many "is my service down?" moments turn out to be platform events, not targeted attacks.
- Look at your service's metrics — sudden traffic spikes, 5xx surges, or auth-endpoint pattern shifts are the first signal.
- Open a support ticket with the affected service name, the timestamp, and any noticeable patterns (geography, headers, paths). The platform team can engage the edge response team for service-specific attack signatures.
Edge protection runs continuously — there's no "turn it on" switch to flip during an attack. The escalation path above is for above-baseline patterns that need a human response.
Honest limits
- No customer-supplied WAF rules. The edge WAF rule set is managed. You can't load your own rules today.
- No customer IP allowlist for the WAF itself. Inbound network access controls live on the service networking page; the WAF below it is managed.
- No bring-your-own edge. Attaching your own Cloudflare / Akamai / Fastly account in front of your ComputeSphere service isn't supported. The protection above is what runs.
- No origin-direct connections. Bypassing the edge to hit your service directly isn't possible — and isn't a feature, it's a deliberate choice. Origins stay private.
- Application-layer logic is your responsibility. Brute-forcing your
/loginendpoint with 100 RPS of valid-looking traffic from 100 IPs reads as legitimate at the edge. Add rate limits and lockouts in your service. - No dedicated per-service mitigation tuning. Bespoke tuning for an active campaign goes through support, not a self-serve dashboard.
What's next
- Architecture — the layered model the edge sits on top of.
- Security — what the platform enforces at every layer, and the shared-responsibility split.
- Networking — public-by-default services and IP allowlist controls on supported tiers.
- Auto-scaling — your second line of defense when a burst gets past the edge.