Vector

Vector is a managed WordPress hosting platform, built API-first and white-label. Partners — agencies, plugin and theme companies, other hosts — provision and operate WordPress sites entirely through our API and resell the result under their own brand. Underneath, WordPress runs serverless, on AWS Lambda, through a deep integration with Ymir. We designed and built the platform end to end: the control plane that orchestrates it, the cloud infrastructure it runs on, the container images sites are built from, and the open-source tooling partners write against. Partners never touch AWS. They make an API call, and the platform handles the rest.

The hard part is orchestration

Managed WordPress hosting looks like a CRUD problem and isn’t. Standing up a single site touches a database cluster, a secrets store, a container scheduler, a load balancer, a DNS provider, a CDN, certificate authorities, and a serverless deployment pipeline — each of them asynchronous, each able to fail on its own, and each needing a different recovery when it does. The engineering that matters in Vector is the coordination layer: running those steps in the right order, making each one idempotent and resumable, and keeping the whole thing observable and safe for many tenants sharing infrastructure. Everything below serves that.

The control plane

The platform is driven by an internal Laravel control plane. Every operation a partner can perform is a versioned REST endpoint — just over a hundred of them, documented and exported as OpenAPI and Postman collections. Authentication is token-based, with fine-grained abilities scoped per resource and action, so a partner can mint a key that lists sites but can’t delete them. Expensive operations — site creation, deployments, database work — are rate-limited per account by category, so read-heavy workflows stay fast while the operations that cost real infrastructure are throttled. Every response shares one envelope, and errors are predictable enough to program against.

Internally, the code is organized around a contract-and-action pattern: every capability is an interface with a single final implementation, wired through dependency injection, and multi-step operations live in dedicated orchestration classes rather than leaking across controllers. External services — AWS, Ymir, the CDN — sit behind configuration toggles, so the platform can run in a degraded mode during an upstream outage, and so the test suite can substitute fakes for live integrations without mocking concrete classes.

Isolation is structural, not incidental. Every query is scoped to the authenticated partner’s account, and every resource policy checks ownership. On a multi-tenant platform that holds other companies’ customers, a cross-tenant data leak is an existential risk, so the codebase is built to make an unscoped query hard to write by accident.

Provisioning a site

When a partner creates a site, the API does the cheap, synchronous work immediately — the record, one-time credentials, a human-readable subdomain, and the production and staging environments — then hands the slow work to a background job. From there the platform provisions a database and user, stores credentials in a secrets manager, registers a container task, wires up load balancer routing, brings the container to a healthy state, and publishes DNS.

Each resource is recorded the moment it’s created. If provisioning fails partway through, the site retains precise references to everything that already exists, so recovery is a targeted retry rather than a guess — a pattern that came directly out of how these systems fail in practice. Sites, environments, and deployments are governed by explicit state machines, so illegal transitions — deploying to a suspended environment, deleting a site with live environments — are rejected by construction rather than caught after the fact.

Deployments

A deploy coordinates our own build pipeline with Ymir’s serverless runtime. The platform generates and validates the deployment configuration, builds the site’s image from source in a managed build service, deploys it to Lambda through Ymir, and waits on each stage with sensible timeouts and signed callbacks rather than blind polling.

Two details matter for speed and safety. Static assets are content-hashed: assets that haven’t changed since the last deploy are copied in place instead of re-uploaded, and the ones that did change are pushed concurrently through presigned URLs — so a CSS- and JavaScript-heavy site doesn’t pay to move bytes that didn’t move. And environment variables and secrets are handled separately by sensitivity: secrets are written to a secrets manager and never returned through the API, while WordPress salts are generated once and persist across redeploys. Rollbacks use Ymir’s native mechanism to return to a known-good release.

DNS, SSL, and the edge

SSL was the most intricate thing to get right, because a single production certificate spans three independent services — the certificate authority through Ymir, our DNS provider for validation, and the CDN for the edge certificate — each answering on its own schedule. Issuance can take seconds or minutes; propagation is unpredictable. Provisioning advances through a step-based, idempotent progression driven by a polling job that tightens its interval while work is progressing and backs off while it’s waiting on someone else. Because every step is safe to repeat, a duplicated or restarted job never corrupts state.

DNS itself sits behind a provider abstraction, so the platform can target different backends without business logic knowing the difference. The CDN and web application firewall are configured through the same API — partners get rate limiting, IP and referrer rules, and DDoS protection without ever talking to the CDN vendor directly.

Infrastructure

Vector’s cloud infrastructure is defined as code and deployed per partner, with isolation that goes all the way down. A shared foundation — networking, an EC2-backed container cluster, image registries, and a single SSH gateway — underpins everything. Each partner gets their own load balancer and wildcard certificate, their own database cluster, and their own cache. Each site, in turn, gets its own database and credentials, its own container task and routing rule, and its own cache scope. A partner’s data and a customer’s data are separated by infrastructure, not by a WHERE clause.

Persistent site files live on durable storage that survives the replacement of the underlying compute, so an instance can be cycled without losing state. SSH and SFTP are multiplexed through one gateway, so every site is reachable at a stable address without exposing the cluster behind it. Logs stream to an external aggregation service, and backups run on a schedule through a dedicated restic-based service with point-in-time restore.

The runtime

Sites are built from container images we maintain — WordPress on Nginx and PHP-FPM, with WP-CLI, SFTP, an object cache, and per-site mail, across the PHP versions we support (8.1 through 8.4). The persistent container gives developers a familiar place to work: edit files over SFTP, run WP-CLI, treat it like a server.

Production is different. The deploy pipeline layers a partner’s code onto Ymir’s ARM Lambda runtime, bundles the WordPress integration plugin, splits static assets out to object storage and the CDN, and ships the result as a serverless function. Production traffic is then served from Lambda that scales with demand and costs nothing at idle — the operational profile of a modern cloud app, applied to WordPress.

What partners build against

Because the platform is API-first, the tools partners use are the same surface we hold ourselves to — and we use them ourselves. All of them are open source:

• A command-line tool, written in Go, that covers the full API — sites, deployments, backups, logs, WAF, secrets. It prints readable tables in a terminal and clean JSON when piped, stores credentials in the OS keychain, ships a built-in query filter, and returns structured exit codes for scripting. It can also register itself as an MCP server, so the entire platform is drivable by an AI agent.
• Node and PHP SDKs with typed clients that mirror the API surface, so partners get autocomplete and type-checking in their own codebase rather than hand-rolled HTTP calls.
• A developer portal whose API reference is generated from the API itself — no second source of truth to drift — alongside an interactive explorer, OpenAPI and Postman exports, and per-endpoint plaintext pages meant to be fetched by AI assistants.

Treating these as first-class products is the real test of an API-first claim. If the SDK is awkward to use, the API is wrong, and we find out before a partner does.

Built to be trusted

A platform that holds other companies’ customers has to be correct, so the engineering standards are part of the product, not overhead around it. The codebase is uniformly strict — every class final, strict types throughout, static analysis and formatting enforced in CI — and backed by a large test suite that fakes external services rather than mocking internals, so the tests exercise real code paths. Credentials are shown exactly once and never retrievable again; sensitive values are marked so they can’t be written to a log by accident; webhooks are HMAC-signed with replay protection; access is account-scoped at the query level. None of this is visible to a partner on a good day. That’s the point — the platform should be the least interesting thing about running their business.