Server Provisioning Pipeline
When you create a server through Puchify, the response returns in under thirty seconds. Most of that time is the hypervisor booting the instance. The orchestration pipeline -- from request to boot command -- completes in under three seconds.
This post describes each step in the pipeline.
Step 1: Authentication and Rate Limiting
The request arrives at the API gateway as a POST to /api/v1/servers. The gateway validates the API key against the HMAC store and checks the per-user rate limit (100 requests per second with burst allowance up to 200). Requests that exceed the limit receive a 429 response with a Retry-After header.
Step 2: Schema Validation
The validated request enters the schema validation layer. Every endpoint has a JSON Schema that defines required fields, type constraints, and value ranges.
Validation errors return a structured response with field-level messages. This enables automated workflows to handle errors programmatically without parsing error strings.
Step 3: Quota Verification
The scheduler checks the user's resource quotas before provisioning. Quotas are enforced per-user and per-project. Each quota tracks server count, total CPU cores, total RAM, and total disk across all active resources. Quota limits are generous by default. Users can request increases through the platform interface.
Step 4: Host Scheduling
The scheduler selects a hypervisor host for the new server. Each host in the pool reports its available resources every 30 seconds. The scheduler scores candidates based on:
- Available capacity (CPU, RAM, local SSD)
- Current load (I/O wait and network saturation)
- Failure domain distribution (physical rack and network switch diversity)
- Density targets (even distribution within a region)
The scheduler uses a scoring function with well-understood weights. Predictable behavior is prioritized over optimal placement.
Step 5: Network Provisioning
While the server boots, the network stack is provisioned asynchronously:
- IP allocation from the regional pool (IPv4 and IPv6)
- VPC attachment (default VPC or user-specified)
- Security group application (default rules plus any user-defined rules)
- DNS record creation (if a hostname is specified)
- Load balancer backend registration (if applicable)
Step 6: Image Deployment
The requested OS image is deployed from the image store -- a distributed file system replicated across three availability zones per region. The deployment process converts the image to raw format, resizes the root partition to match the plan specification, and injects cloud-init metadata with the user's SSH key and configuration.
Custom images are supported. Upload a qcow2, raw, or VMDK image. The platform converts and snapshots it for future use.
Step 7: Boot and Health Check
The hypervisor boots the instance with the provisioned disk and network configuration. The health checker polls for SSH availability every two seconds. Once SSH connectivity is confirmed and the Puchify agent reports a heartbeat, the server status transitions to running.
Pipeline Timing
| Step | Component | Typical duration |
|---|---|---|
| Authentication | API gateway | ~5ms |
| Validation | Schema engine | ~2ms |
| Quota check | Postgres | ~8ms |
| Scheduling | Scheduler | ~15ms |
| Network provisioning | IPAM + VPC | ~300ms |
| Image deployment | Storage layer | ~1800ms |
| Boot | Hypervisor | ~14000ms |
| Health check | Polling system | ~200ms |
Response
The server is ready for SSH connections and API operations. From this point, all standard resource operations apply: status queries, metrics retrieval, snapshot creation, plan upgrades, and termination.