Isolated project runtime
Each Enfyra Cloud project runs inside its own Enfyra runtime boundary. Project configuration, credentials, owner access, runtime process, and project URL are separated from other Cloud projects.
Shared managed infrastructure
Some supporting resources, including database capacity, edge routing, and platform services, are operated as managed pools. This lets Enfyra Cloud use available headroom efficiently when nearby workloads are idle, while still keeping each project runtime isolated.
Headroom scheduling
Enfyra Cloud does not sell a fixed physical slice of a host for every project. Instead, the platform places projects using reservation targets, operational headroom, and current capacity signals. The goal is to keep enough room for active projects, background services, and normal bursts without publishing raw host-level ratios.
Fair-use guardrails
Edge and runtime guardrails help prevent one project from consuming shared resources in a way that harms other active projects. These controls are part of the service boundary and may include traffic shaping, runtime limits, admission checks, and operational intervention when a workload behaves outside the intended plan envelope.
How plans differ
Higher Cloud plans are scheduled with more practical headroom per project. Developer and Business plans reduce the number of projects admitted into the same capacity pool, so each active project has more room for sustained usage. This does not mean every higher plan receives a dedicated physical machine; it means the platform reserves a larger operating envelope for that project.
No public capacity ratio
Enfyra Cloud does not publish exact per-host tenant counts, CPU ratios, database pool sizes, or other raw placement numbers as customer guarantees. Those values can change as the platform improves hardware, routing, database tuning, and guardrail behavior. Customer-facing plan descriptions should be read as service envelopes rather than fixed hardware allocations.