Limitations

Previous Next

This page lists the most important current product limits so operators and contributors do not have to infer them from scattered documents.

Architectural Limits

  • Spooky is centered on HTTP/3 downstream with scheme-driven upstream transport: https:// backends use HTTP/2, http:// backends use HTTP/1.1. Mixed deployments are supported.
  • It is not yet a broad multi-protocol reverse proxy in the same class as older general-purpose incumbents.
  • It is not yet a dynamic control-plane-driven proxy platform.

Configuration And Control Plane Limits

  • Full configuration hot reload exists for runtime-managed settings, but some startup-owned changes still require a restart.
  • Dynamic route updates are not implemented as a first-class runtime feature outside config reload.
  • Dynamic upstream membership changes are limited to DNS refresh rather than a richer control-plane API.
  • There is no transactional apply, generation diff, rollback, or staged config activation model.

Protocol Limits

  • Upstream HTTP/3 forwarding is not implemented.
  • CONNECT support exists only as a constrained policy feature, not as a broad proxy capability.
  • WebSocket and upgrade handling are limited and are not yet a full-feature parity surface.

Traffic-Management Limits

  • No route-level weighted traffic splitting.
  • No request mirroring or shadow traffic.
  • No built-in fault injection layer.
  • No full request/response rewrite/filter pipeline.

Security And Policy Limits

  • No JWT validation.
  • No OIDC or full auth gateway feature set.
  • No external authorization filter.
  • No RBAC or generic policy engine.
  • No WAF or advanced request-inspection layer.

Platform And Ecosystem Limits

  • No Kubernetes-native control plane or operator.
  • No xDS-style fleet management.
  • No plugin or extension model.
  • No service-mesh positioning or mesh-native runtime integration.

Engineering Limits

  • The central edge runtime remains concentrated in a very large module.
  • This increases change risk and makes long-term feature growth harder.
  • Some docs and operational guidance still need tighter separation between stable behavior and future intent.

What These Limits Mean In Practice

Spooky is a strong candidate when:

  • HTTP/3 edge performance and correctness are primary goals
  • the upstream environment speaks HTTP/2 (https:// backends) or HTTP/1.1 (http:// backends), or a mix of both
  • the deployment can tolerate occasional restarts for startup-owned config changes
  • the deployment does not require rich traffic policy or auth gateway features

Spooky is a poor fit today when:

  • every config field must be live-reloadable with no restart boundary
  • upstream protocol breadth is required
  • advanced API gateway behavior is required
  • a rich dynamic control plane is expected
  • a plugin/filter ecosystem is required
Feature Matrix Terminology