Provisionnement < 15 secondes

Du clic à un backend pleinement opérationnel en moins de 15 secondes. Workflow détaillé control plane global → control plane local → routing.

15 secondes du clic au backend prêt

Le provisionnement d'un backend Pool C est conçu pour être instantané — moins de 15 secondes du clic à un PostgreSQL pleinement opérationnel, services data plane démarrés et endpoints HTTP routés. À titre de comparaison, un BaaS public standard prend 30 à 90 secondes pour le même résultat.

Quand provisionner — quand attendre

Idéal pour

  • Démos commerciales — backend prêt avant la fin de la phrase
  • Preview environments par PR (cf. branching)
  • Onboarding produit — pas d'écran « patientez »
  • Tests d'intégration : un backend neuf par run CI

À éviter

  • Création en boucle pour scripts (préférer le branching copy-on-write)
  • Provisionnement manuel pour un usage unique < 1 minute

Créer via la CLI

paas backends create my-backend \
  --region eu-west-1 \
  --tier pro \
  --extensions vector,graphql

# Sortie : project_id, URL, anon_key, service_role_key, connection string

Créer via API REST

curl -X POST https://console.di2amp.com/api/v1/backends \
  -H "Authorization: Bearer $PAAS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "my-backend",
    "region": "eu-west-1",
    "tier": "pro",
    "extensions": ["vector", "graphql"]
  }'

# Réponse 202 :
{
  "project_id": "wzfbhd",
  "status": "provisioning",
  "url": "https://wzfbhd.runtime.di2amp.com",
  "estimated_ready_at": "2026-05-12T10:00:15Z"
}

Comment ça marche

Le workflow se découpe en trois phases :

PhaseDuréeÉtapes principales
1 — Control plane global< 2 sValidation tenant, génération project_id (6 lettres uniques), placement cluster, gRPC vers control plane local
2 — Control plane local2 à 12 sGénération credentials chiffrés KMS, création dataset isolé, démarrage container PostgreSQL, installation extensions, démarrage services data plane
3 — Routing< 1 sPush de la route vers la passerelle d'API, cache Redis global, activation projet

project_id collision-proof

Le project_id est un identifiant aléatoire de 6 lettres minuscules [a-z]{6}, soit 308 millions de combinaisons. Vérification d'unicité globale à chaque création. Mémorisable, lisible, utilisable directement comme sous-domaine. Le cluster_id interne (lui aussi 6 lettres) n'est jamais exposé.

Exemples : wzfbhd, kxnpqr, mfrdth.

Limites par plan

PlanBackends maxTemps de provisionnement
Free1< 15 s
Pro5< 15 s
Businessillimité< 15 s
Entrepriseillimité< 15 s

La durée est identique quel que soit le plan ; seules les ressources allouées (RAM, CPU, quota disque) varient.

Sécurité et isolation

Les credentials générés (mot de passe PostgreSQL, jwt_secret, anon_key, service_role_key) sont produits par une source aléatoire cryptographique du compute, chiffrés via vault secrets KMS et stockés. La service_role_key n'est affichée qu'une seule fois à la création — elle doit être stockée côté serveur uniquement, jamais embarquée dans une app cliente.

Pour aller plus loin

Tarification associée

Le provisionnement lui-même n'est pas facturé. Le backend est facturé selon le tarif du plan dès qu'il est en état actif (Free = gratuit avec auto-pause).