The Praxys Runtime Engine: the backbone behind our platform

Solving these problems separately in every service makes reliability inconsistent. One service has graceful shutdown; another drops in-flight work. One emits useful traces; another is difficult to diagnose.

Praxys takes a different approach. The Praxys Runtime Engine is the common backbone beneath our own APIs and application stack. It provides the execution model, lifecycle controls, routing, and scaling mechanisms on which first-party services are built. That shared foundation lets teams concentrate on product logic while the platform applies the same operational discipline everywhere.

One substrate, many service shapes

At the base of the architecture is runtime-core, the shared execution substrate for every Praxys runtime variant. A runtime variant is built on the core and inherits its lifecycle, clustered-worker model, health signals, structured logs, telemetry, controlled egress, and artifact-update machinery.

The core deliberately does not prescribe an I/O surface. It does not assume that a service receives HTTP requests, consumes queue messages, or runs on a schedule. Instead, specialised runtime packages compose the same substrate into the shapes the platform needs:

• runtime-web serves HTTP applications, with route dispatch, standard middleware, authentication and rate-limit integration, SSE, MCP, OAuth, and OpenAPI generation.
• runtime-cron runs the background plane: scheduled jobs, queue consumers, pub/sub subscriptions, and durable workflows.
• runtime-webhooks receives third-party events, verifying signatures before processing, preventing replay and duplicate delivery, and optionally dispatching work asynchronously.
• runtime-host is the hosting and lifecycle layer for deployed applications. It coordinates deployment, tracks application endpoints, and proxies traffic to the running instance.

The surfaces focus on how work arrives; runtime-core focuses on how work runs. A new service selects the appropriate runtime shape and implements its domain behavior rather than rebuilding the operational foundation.

Reliability as a platform property

Shared infrastructure matters most when something goes wrong. runtime-core evaluates system, runtime, and traffic health signals. Those signals drive circuit breakers, load shedding, admission control, restart policy, and graceful degradation: protecting healthy components, rejecting work deliberately when necessary, and making the condition visible through logs, metrics, and traces.

The runtime also supports staged, blue-green artifact updates: a new version is prepared and checked before new work is directed to it, while in-flight work on the old version drains. If the new artifact is not healthy, the existing version remains in place. Worker clustering and interruption-aware lifecycle handling add resilience when a machine needs replacement.

These are capabilities of the substrate, not conventions each service team must remember to implement. Improving a health policy, drain path, or telemetry signal improves every service built on it.

Safely landing traffic and capacity

Around the running runtimes sit two complementary control-plane components: the gateway and the autoscaler.

The gateway is the stateless traffic-routing tier. It resolves a request to a serving host set, uses deterministic weighted rendezvous hashing to keep related requests stable, and spills to another host when the preferred one is unhealthy or saturated. Its session-affinity token is a routing aid, not an identity signal. If it cannot produce a healthy destination, it returns a retryable response.

The autoscaler makes capacity decisions without directly manipulating machines. It observes load and writes a desired placement plan: whether an application needs more copies, can scale down, or should receive a different spill weight. Hosts reconcile that plan and claim work themselves. This “hints, not commands” design keeps the autoscaler off the request path and limits the effect of stale data or a transient control-plane failure. Threshold hysteresis, bounded step sizes, and warm floors prevent capacity from flapping under variable traffic.

The stack at a glance

⤢ enlarge

×

Every workload rests on the same runtime core, while routing, hosting, and scaling operate through clear contracts around it. The platform can evolve individual services without abandoning its operating principles.

Built for Praxys — and for the applications we host

We built this backbone first to hold Praxys itself together. It gives our application stack a consistent way to start, update, observe, route, and recover. But it was never intended to be an internal-only advantage.

Customer applications hosted on Praxys are designed to benefit from the same runtime architecture: the lifecycle discipline, safe routing, resilient deployment model, and capacity controls that underpin our services. Building on Praxys means building on the platform standards we depend on ourselves.

The runtime also contains capabilities for isolating workloads and handling tenant context. Those deserve their own treatment alongside the broader security model.