Architecture
Understanding Vector's architecture is important because it represents a significant departure from traditional WordPress hosting—and that departure is what enables the scalability and reliability.
The Core Concept
Traditional WordPress hosting runs on servers that are always on, waiting for requests. You pay for that capacity whether you use it or not, and when traffic exceeds capacity, the site slows down or crashes.
Vector flips this model. Instead of always-on servers, Vector deploys WordPress to serverless infrastructure that spins up on demand. When a request comes in, the infrastructure responds. When traffic is low, you're not paying for idle capacity. When traffic spikes, the infrastructure scales automatically—no intervention required.
This is what makes "survive Black Friday without thinking about scaling" possible.
Sites and Environments
When you create a site through Vector Pro, you're creating a container for multiple environments:
Each environment is isolated. They don't share databases or files. This means you can safely test changes in staging without any risk to production.
Development Environment
The development environment is different from the others. It runs on a container (not serverless infrastructure) and provides the full WordPress experience:
- WP Admin access — All WordPress administration happens here
- SFTP access — File uploads go to the development environment
- Plugin/theme installation — Install, update, and configure WordPress as usual
- Content creation — Posts, pages, media—all managed in development
Think of development as the "workshop" where your customer builds and maintains their WordPress site. It's familiar, it works like WordPress always has, and it gives full access to everything WordPress offers.
The development environment is accessed via a subdomain on your partner domain (e.g., happy-panda.yourpartnerdomain.com).
Deployed Environments (Staging, Production, Custom)
Staging, production, and any custom environments are fundamentally different from development. They run on serverless infrastructure, which enables the automatic scaling—but it also means some things work differently.
Key difference: No writes in production.
Deployed environments are read-only from WordPress's perspective. There's no WP Admin, no plugin installation, no file uploads, no content editing. The deployed environment serves the site—it doesn't allow changes to it.
Serverless infrastructure doesn't have a persistent filesystem in the traditional sense. When a request comes in, the infrastructure spins up, handles the request, and spins down. Any files written during that request don't persist. This is what makes the scaling possible—there's no server state to manage—but it means WordPress's assumption that it can write to the filesystem doesn't hold.
What this means in practice:
- All WordPress work (content, plugins, themes, settings) happens in development
- Deploys take a snapshot of development and push it to the target environment
- The deployed environment serves that snapshot
- To make changes, you make them in development and deploy again
For content-heavy sites, this workflow might feel unfamiliar at first. But it also means deployed sites are predictable and reproducible—what you deploy is exactly what runs, every time.
Environment Domains
Each environment gets a subdomain on your partner domain:
- Development:
happy-panda.yourpartnerdomain.com - Staging:
quick-fox.yourpartnerdomain.com - Production:
bright-star.yourpartnerdomain.com
These are randomly generated word-pair subdomains. Production environments can also have custom domains attached.
The Deployment Flow
Deploying pushes code and assets from development to a target environment. Here's what happens:
PHP files are packaged
The WordPress core, themes, plugins, and any custom code are prepared for serverless deployment
Assets go to cloud storage
Uploaded media and static files are pushed to cloud storage where they're served efficiently
Environment becomes active
Once deployment completes, the environment is live and serving traffic
Important: Databases are separate
Deployments push code and assets only—they do not copy the development database. Each environment maintains its own independent database. This separation is intentional. It prevents accidental data overwrites and gives you control over what content exists in each environment.
Deploys are triggered via API call. Your integration can trigger them manually, or you can build automation (CI/CD pipelines, scheduled deploys, etc.) on top of the API.
Current state: Today, all deploys originate from development. If you deploy to staging, test, then deploy to production, both deploys come from development's current state.
Future capability: We're building a "promote" feature that will allow promoting one environment directly to another (e.g., staging to production), enabling more sophisticated deployment workflows.
DNS and CDN
Vector uses a layered approach to DNS and content delivery.
CDN (Production Only)
Production environments include CDN for performance and protection:
- Global edge caching — Static content is cached at edge locations worldwide
- Intelligent caching — The CDN is configured for WordPress, so dynamic content (cart, checkout, logged-in experiences) remains dynamic while static content is cached aggressively
- DDoS protection — The CDN layer provides protection against volumetric attacks
- WAF — Web Application Firewall rules block common attack patterns
Non-production environments (staging, custom) don't include CDN. They're meant for testing and review, not for serving production traffic.
SSL Certificates
SSL is automatic. When a custom domain is attached to a production environment, Vector Pro provisions and manages the SSL certificate. Partners and their customers don't need to deal with certificate generation, installation, or renewal.
Database Architecture
Each environment has its own completely independent database:
- Development has a database where all content creation and WordPress administration happens
- Each deployed environment has its own separate database that persists independently
- Databases are fully isolated—changes in one environment never affect others
What Happens Under Load
This is where the serverless architecture really matters.
Traditional hosting: Traffic spike → Server overloaded → Site slow or down → Scramble to add capacity → Customers frustrated
Vector: Traffic spike → Infrastructure scales automatically → Site stays fast → You don't even notice
For partners, this means you can confidently sell hosting without caveats about traffic limits or overage fees. For your customers, it means their site stays up during their most important moments—product launches, viral content, Black Friday.
Lifecycle and States
Sites, environments, and deployments each progress through defined states. Understanding these states helps you build integrations that respond appropriately.
Site Lifecycle
When you create a site, it goes through provisioning before becoming available:
pending → active
- pending — Site creation has been initiated. The development container is being provisioned.
- active — Provisioning is complete. The development environment is accessible.
- suspended — The site has been suspended and is not accessible.
- failed — Provisioning failed.
Environment Lifecycle
pending → active
- pending — Environment creation has been initiated.
- active — The environment is ready for deployments.
Deployment Lifecycle
pending → deploying → deployed (or failed)
- pending — Deployment has been queued.
- deploying — Deployment is in progress.
- deployed — Deployment completed successfully.
- failed — Something went wrong.
Architecture Summary
| Component | Development | Deployed Environments |
|---|---|---|
| Infrastructure | Container | Serverless |
| WP Admin | Yes | No |
| SFTP | Yes | No |
| Writes | Yes | No |
| CDN | No | Production only |
| SSL | Auto | Auto |
| Scaling | Fixed | Automatic |
| Database | Persistent | Independent per environment |