Per-site PHP policy
Worker counts and idle behavior belong to the site's traffic pattern, not a shared default copied everywhere.
MANAGED WORDPRESS HOSTING · IN DEVELOPMENT
Carts. Checkouts. Accounts. The moments when WordPress has to do real work deserve more than a one-size-fits-all server preset.
A hosting platform taking shape in a local lab. No speed guarantees or signups before the evidence is there.
THE PROBLEM WE'RE SOLVING
A visitor browsing a cached homepage and a customer loading their cart can experience two very different websites. Dynamic requests reach PHP, the database, and the limits of the server underneath.
We're designing hosting around those uncached paths: using workload evidence to choose worker behavior, cache capacity, resource limits, and operational guardrails for each site.
THE PLATFORM, BY DESIGN
Infrastructure choices should follow the site's workload — and remain visible, reversible, and testable.
Worker counts and idle behavior belong to the site's traffic pattern, not a shared default copied everywhere.
See what happens when a request bypasses full-page cache — across PHP, database, and the hosting node.
Separate site resources, controlled changes, and backups that are tested by restoring them.
Every tuning decision needs an observed result, an audit trail, and a reliable path back.
BUILD IN THE OPEN, CLAIM LESS
WP Velocity Lab is still a development project. We're proving the hosting layer before inviting production sites or selling a performance promise.
Back to the beginningShared-node architecture and WordPress storefront clones.
Versioned changes, readback, and account-specific rollback.
Bringing site ownership, operations, and observability together.
Only after security, recovery, and capacity gates pass.