# Full deployment (/deployments/full-deployment)



## What Crucible provisions [#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](/environment-variables/)**: Standard integration variables, Auth Service wiring, and LLM Gateway access before the deployment applies.
* **[Observability](/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 [#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.

```mermaid
sequenceDiagram
  participant A as Project admin
  participant C as Crucible
  participant R as Repository
  participant Y as Project's cloud
  A->>C: New deployment
  C->>R: Opens pull request
  A->>R: Review and merge
  R->>C: Merge reaches config branch
  C->>Y: Provision deployment
  C-->>A: Status in Deployments
```

<Steps>
  <Step>
    **Start the deployment**

    Open the project's **Deployments** tab, select **New deployment**, then choose **Full** as the type.
  </Step>

  <Step>
    **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**.
  </Step>

  <Step>
    **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.
  </Step>

  <Step>
    **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.
  </Step>
</Steps>

<Accordions>
  <Accordion title="Under the hood: configuration approval">
    * **Repository-owned declaration**: The pull request adds the deployment to `deployment.environments` in `project.yaml` on 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 `main` commit before writing its Terraform environment root.
  </Accordion>
</Accordions>

## Cloud runtime [#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](/deployments/full-deployment/azure-deployment-checklist/).

<Accordions>
  <Accordion title="Under the hood: how the cloud split works">
    <Tabs items="[&#x22;GCP&#x22;, &#x22;Azure&#x22;, &#x22;AWS&#x22;]">
      <Tab value="GCP">
        GKE, Cloud SQL, Cloud Storage, Secret Manager, Artifact Registry, Cloud DNS, and a load balancer with managed certificates for frontend delivery.
      </Tab>

      <Tab value="Azure">
        AKS with a private API server after bootstrap, Azure Database for PostgreSQL Flexible Server, Blob Storage, Key Vault, Azure Container Registry, Azure Front Door, Azure DNS, and managed identities.
      </Tab>

      <Tab value="AWS">
        EKS, RDS, S3, Secrets Manager, ECR, CloudFront, Route 53, ACM certificates, and CodeBuild for bootstrap.
      </Tab>
    </Tabs>

    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.
  </Accordion>
</Accordions>