Provisioning must be asynchronous. Creating a server, waiting for networking, validating DNS, and registering checks can take longer than a web request should handle.
Flow
- A customer submits a server request or completes payment.
- The app writes a server record and a provisioning job to Supabase.
- A BullMQ job is pushed to Redis.
- A worker creates the server through Hetzner or Netcup.
- The worker waits for IPv4 assignment.
- The worker installs the selected runtime, such as Coolify.
- DNS records are created through Cloudflare when needed.
- Health checks are registered in Uptime Kuma.
- The dashboard receives updated status and event history.
Job states
| State | Meaning |
|---|---|
| Pending | Request is stored but not claimed by a worker yet. |
| Provisioning | Provider work or runtime installation is in progress. |
| Waiting | An external dependency is not ready yet, such as DNS propagation. |
| Online | Server is ready and checks are registered. |
| Failed | The worker needs operator review or retry. |
Worker requirements
Provisioning jobs should be idempotent. Retrying a job must not create duplicate provider servers, duplicate DNS records, or duplicate monitoring checks.
Every long-running step should write a durable event so the dashboard can show useful progress instead of a vague loading state.