Current Stage: Beta

Spooky is currently beta. That means:

• the core H3 edge to upstream flow (H2 and H1) is implemented and heavily exercised
• the project has meaningful operational and correctness work in place
• broader platform maturity, control-plane depth, and production-history confidence are still incomplete

Beta does not mean:

• full reverse-proxy feature parity with Envoy, NGINX, or Caddy
• full dynamic config management
• broad protocol parity across legacy and modern upstream shapes

What Operators Can Assume Today

Operators can reasonably assume:

• the project is serious about correctness on its core path
• the docs now state key limitations explicitly
• controlled production rollout is the right stance

Operators should not assume:

• every interface is frozen
• every deployment shape has been equally hardened
• a fully restart-free config workflow exists — most runtime-managed config applies live through the staged validate, preview, and activate flow, but log format/file settings, tracing config, control-plane thread counts, and listener removal/bind-address changes still require a restart

Current Strong Areas

• downstream HTTP/3 ingress
• downstream bootstrap HTTP/1.1 and HTTP/2 support
• upstream HTTP/2 forwarding (https:// backends) and HTTP/1.1 forwarding (http:// backends)
• deterministic routing
• multiple load-balancing strategies
• strong teardown and resource-bound behavior
• active and passive health handling
• built-in observability and control-plane surfaces

Current Hardening Gaps

• full config hot reload
• richer dynamic control plane
• upstream HTTP/3 forwarding and broader upstream protocol support
• stronger service-discovery integrations
• auth, policy, and rate-limiting feature depth
• broader ecosystem and long-horizon production history

GA Direction

The most important maturity gates before a broader GA-style claim are:

1. full config hot reload or an equally strong dynamic reconfiguration model
2. stronger parser and protocol hardening, including fuzzing
3. broader production validation across load, churn, and failure scenarios
4. clearer support boundaries and upgrade discipline
5. continued refactoring of the most concentrated runtime code

Beta Deployment Guidance

• use canaries or bounded traffic first
• keep rollback warm and tested
• apply most runtime-managed config changes live through POST /admin/runtime/validate, POST /admin/runtime/preview, and POST /admin/runtime/activate; use the legacy POST /admin/runtime/reload shortcut only when you intentionally want the older direct-apply path
• drain-and-restart for log format/file settings, tracing config, control-plane thread counts, and listener removal or bind-address changes
• read release notes before upgrade
• pin to tagged versions, not moving branches

Related Docs

• Production Readiness
• Feature Matrix
• Limitations
• Roadmap