Runtime Topology and Deployment Modes

The platform supports several deployment topologies, but they all preserve the same internal model: one native application runtime, explicit backing services, and customer apps composed into the host binary or installation. Different topologies change where transport, storage, and coordination live; they should not force the application itself to behave differently.

Single-node deployment is the simplest mode and the best fit for local development, tests, and smaller environments. In this mode the HTTP runtime, scheduler, workers, local cache, and any local-only sensitive storage can coexist on the same machine. This topology is operationally simple and useful when the team needs to reason about the entire system in one place.

Multi-node deployment is the normal production target for larger customer apps. Request handling should be stateless by default, with shared queue and distributed cache infrastructure providing coordination. Object storage becomes the durable store for public assets, public uploads, and private shared uploads, while per-node local caches act only as acceleration layers. Scheduler leadership must be explicit so that certificate renewal, sitemap generation, imports, or other scheduled work does not run on every node at once.

TLS can be handled in two main ways. In direct-termination mode, the platform owns certificate lifecycle and terminates HTTPS itself. In external-termination mode, the platform sits behind a load balancer, CDN, or edge provider and trusts forwarded transport metadata only from configured proxies. Core needs to support both models because some customer apps will want a simpler origin behind Cloudflare or a similar edge, while others may terminate directly at the application.

When the platform manages certificates itself, ACME is the primary path and Cloudflare-specific operation is a first-class case rather than a workaround. The runtime should support http-01, tls-alpn-01, and dns-01 challenges, with dns-01 treated as the preferred mode for wildcard certificates, multi-node deployments, and CDN-fronted setups. Cloudflare support should be modeled in two explicit ways: public certificates issued through ACME with Cloudflare DNS automation, and origin-only certificates issued through Cloudflare Origin CA when the origin is intended to be reached only through Cloudflare. In that second case, the expected operational mode is Cloudflare Full (strict).

Storage topology is equally important. Public deploy assets and public uploads should normally be backed by S3-compatible object storage and delivered through a CDN or equivalent edge cache. Private shared assets should also default to object storage, but without public delivery. A local_only_sensitive path remains valid for files that must stay on the server, but it is an exception with operational cost: it breaks the default stateless multi-node model and therefore requires single-node deployment, a shared private volume, or explicit request affinity.

The design goal across all of these modes is consistency. A customer app may choose its hostname strategy, certificate provider, storage rules, and edge setup, but the runtime still provides one model for request handling, authorization, caching, jobs, and asset delivery. Topology should change operational envelopes, not platform semantics.