Provisioning & Orchestration

Purpose

The provisioner manages the full lifecycle of slices — from creating databases and Docker containers to assigning them to users and destroying them on cancellation. It maintains a warm pool of at least 1 available slice so new users never wait.

Architecture

Provisioning Steps

1. Calculate next available port (5001, 5003, 5005…)
2. Create PostgreSQL database: wa_slice_{N}
3. Apply CRM schema from /home/ubuntu/whatsapp/deploy/saas/slice-schema.sql
4. Grant all permissions to wa_slice database user
5. Create data directories: /data/slices/{N}/media/ and /data/slices/{N}/session/
6. Start Docker container with resource limits, volume mounts, database URL
7. Register in gateway.slices table (status: available)
8. Wait for health check (up to 60s, polling every 2s)

Destruction Steps

1. Stop Docker container
2. Remove Docker container
3. Drop PostgreSQL database (wa_slice_{N})
4. Delete data directory (/data/slices/{N}/)
5. Unlink user (set slice_id = NULL)
6. Delete row from gateway.slices

Assignment Flow

When a user registers (and billing is disabled or payment confirmed):

1. Query for first available slice: SELECT id FROM gateway.slices WHERE status = 'available' ORDER BY id LIMIT 1
2. Update slice: status = 'assigned', user_id = {userId}
3. Update user: slice_id = {sliceId}
4. If no available slices, user enters “provisioning wait” screen (polls every 3s)
5. Monitor loop detects available < 1, auto-provisions a new slice within ~60s

Pool Management

The ensureSlicePool() function runs every monitor cycle (60s):

1. Find users with no slice → try to assign available slices
2. Count available slices
3. If below minimum (1) → provision a new slice
4. After provisioning → try to assign any still-waiting users

A provisioning lock prevents concurrent provisioning operations.

API Endpoints

Handshakes

Status

Operational. Auto-provisioning maintains warm pool. 2 slices currently assigned, pool management active.