Provisioning workflow
The durable workflows that build a new project's repository, integrations, and first runtimes, and each full deployment's infrastructure.
How a project is built
Creating a project replaces a long infrastructure checklist with one observable workflow. Crucible sets up sign-in, the repository, and integrations first, then starts the first runtimes and marks the project ready when they are live.
- Prepare sign-in: Crucible creates the project's sandbox and production sign-in projects before anything else, so project access can sync to them from the start. See Auth sandboxes.
- Set up the repository: Crucible creates a GitHub repository, copies the selected template into it, and commits the project-specific starting files.
- Connect standard integrations: Crucible adds the template's default integrations:
- Sign-in for your users, through Auth
- Model calls through the LLM Gateway
- Runtimes for workspaces and lite deployments
- Sandboxes for agent chats
- Durable workflow namespaces for full deployments
- Ciridae MCP access
- Feedback to Linear, when the organization has connected Linear
- Start the first runtimes: In parallel, Crucible starts the "Dev" lite deployment on the subdomain you chose and a starter workspace.
- Mark the project ready: The project turns healthy once every runtime is live.
The project page shows each step as it runs. Crucible retries transient failures automatically, and a step shows "Retrying" while it does. If a step still fails, setup stops, the project shows "Needs attention", and the failed step's error stays on the page.
ProvisionProjectWorkflow is a Temporal workflow. It creates the sandbox and production Auth projects (production is skipped in sandbox-only installations), creates an empty repository, bootstraps it from the template and rewrites deployment.mode in project.yaml, then adds each default standard integration in turn: auth_service, llm_gateway, temporal, modal, ghost_envs, ciridae_mcp, and linear (skipped when the organization has not connected Linear). It pre-creates the deployment and workspace records, starts one child workflow per runtime, and waits for all of them. Each activity has its own retry policy; once retries run out, the workflow fails with a non-retryable error and the project is marked failed.
How a full deployment is built
Full deployments are provisioned separately from project creation, when you create one. Each gets its own isolated cloud environment, built and deployed by one durable workflow. On GCP, the default:
- Stand up the cloud project: A dedicated cloud project for the deployment, with billing attached.
- Connect sign-in: Crucible registers the deployment's sign-in callback URL with its sign-in project.
- Build the infrastructure:
- Identity and access: separate service accounts for delivery, builds, and each workload
- Networking: a private network and a private Kubernetes cluster
- Load balancing: load balancers for the frontend and the API, a firewall in front of the API, and a CDN in front of the frontend
- Data: a managed Postgres database on the private network, object storage, and a Redis cache for the Agents template's agent runtime
- Secrets: encrypted, versioned secret storage synced into the cluster
- Compute: the backend API and background worker, plus a registry for container images
- DNS and certificates: a DNS zone for the deployment's subdomain and managed TLS certificates
- Continuous delivery: a release pipeline that runs inside the cluster
- Operations: in-cluster logs, metrics, and critical alerting
- Delegate DNS: Crucible delegates the deployment's subdomain to its DNS zone.
- Build and deploy the code: The release builds the backend image and the frontend, runs database migrations and declares scheduled workflows, rolls out the API and worker, uploads the frontend, then refreshes the CDN cache.
- Finish: Crucible installs its connector in the cluster and marks the deployment ready.
Azure deployments follow the same shape with Azure services. See the Azure deployment checklist.
ProvisionEnvironmentWorkflow creates a GCP project in a per-project folder, attaches billing, enables APIs, and creates the Terraform apply service account. One Cloud Build job runs the first Terraform apply from infra/environments/<env>. The environment uses a private GKE cluster reached through Connect Gateway; Cloud SQL with private IP only, encrypted connections, and point-in-time recovery; Cloud Storage; in-cluster Redis (primary and replica) and a Temporal worker when agents_enabled is on; Secret Manager synced by External Secrets; Artifact Registry; Cloud DNS; a global HTTPS load balancer with Cloud CDN for the frontend bucket; GKE Ingress with Cloud Armor for the API; and Loki, Prometheus, and Alloy. Releases are Argo Workflows runs submitted by Crucible, not Cloud Build triggers. The Terraform apply service account holds the Owner role on the environment's project.