Full deployment
A dedicated, SOC 2 ready cloud environment for software your users and business depend on.
What Crucible provisions
Use a full deployment when real users depend on the project and you need production operations: a dedicated environment, DNS, metrics, and the full observability path. Crucible provisions it end to end, and the team ships the product instead of assembling cloud infrastructure.
- Cloud environment: A dedicated cloud environment boundary with the services and identities the project needs to run.
- Runtime and DNS: The deployed backend, frontend delivery path, DNS, certificates, and running URLs.
- Managed configuration: Standard integration variables, Auth Service wiring, and LLM Gateway access before the deployment applies.
- Observability: Error reporting and product analytics through the organization's own Sentry and PostHog accounts, once the project adds those integrations.
Create a full deployment
Project admins create full deployments. Each one is declared in the repository's project.yaml, and the team approves it through a pull request before Crucible creates any cloud resources.
Start the deployment
Open the project's Deployments tab, select New deployment, then choose Full as the type.
Set the deployment
Enter a name (lowercase letters, digits, and hyphens) and branch, and choose Sandbox or Prod for Auth. To change the default subdomain, open Advanced settings and set Subdomain. Select Create.
Approve the configuration
If the deployment is not declared yet, Crucible opens a pull request that adds it to project.yaml; no cloud resources exist at this point. Select Open pull request, then review and merge it.
Follow provisioning
Crucible starts provisioning when the merge reaches the project's environment config branch. The deployment appears in Deployments with its status; no second create request is needed.
- Repository-owned declaration: The pull request adds the deployment to
deployment.environmentsinproject.yamlon the project's environment config branch (project Settings, Advanced settings). - Merge-triggered reconciliation: The push to that branch is the approval event. Crucible finds the newly declared deployment and starts its durable provisioning workflow.
- Missing branch creation: The deployment branch may not exist when the pull request opens. Provisioning creates it from the latest
maincommit before writing its Terraform environment root.
Cloud runtime
Full deployments run on the cloud chosen for the project at creation: GCP, Azure, or AWS. Azure and AWS are offered once the organization connects them. Backend services and deployment-time tasks run as Kubernetes workloads, and provider-native services carry the database, storage, secrets, DNS, identity, registry, delivery, and networking, which keeps the project contract the same on every cloud. For Azure setup, use the Azure deployment checklist.
GKE, Cloud SQL, Cloud Storage, Secret Manager, Artifact Registry, Cloud DNS, and a load balancer with managed certificates for frontend delivery.
Shared Kubernetes and Argo Workflows modules keep workloads, migrations, rollouts, and deployment modes aligned across clouds. Provider modules own cloud-specific networking, identity, storage, secrets, DNS, artifact delivery, and the external submission path.