# Day 2 Operations

After you deploy an [environment](https://bluebricks.co/docs/core-concepts/environments), your infrastructure needs change. These post-deployment changes are commonly called Day 2 operations. It refers to everything you do to a running environment after the initial provisioning, from scaling compute to adjusting storage to reconfiguring clusters.

## How Day 2 changes work in Bluebricks

Every environment in Bluebricks is backed by a [blueprint](https://bluebricks.co/docs/core-concepts/packages/blueprints-overview) that declares the desired state of your infrastructure. When you need to change a deployed resource, you update the relevant [input values](https://bluebricks.co/docs/core-concepts/packages/inputs-and-outputs#how-inputs-get-their-values) and start a new run. Bluebricks generates a plan that shows exactly what will change, and applies only the difference.

The core workflow is:

1. **Identify the input to change** in the blueprint (e.g., `vm_size`, `disk_size_gb`, `node_count`)
2. **Update the input value** in your Git-managed manifest, through the Bluebricks app, or via the CLI
3. **Push the change** (Git) or **start a new run** (app/CLI) to generate a plan and apply the change
4. **Verify the result** in the run logs and your cloud provider console

{% hint style="info" %}
Bluebricks does not modify resources directly. It updates the IaC configuration and delegates execution to the underlying engine (Terraform, Helm, CloudFormation, Bicep). The cloud provider determines how each change is applied, whether in-place or via replacement.
{% endhint %}

## Targeting an existing environment

If your environment is connected to a Git repository through [GitOps environments](https://bluebricks.co/docs/core-concepts/environments/gitops-environments), update the input values in your source code or manifest file and push the change. Bluebricks detects the update, generates a plan, and applies it automatically. Pull requests trigger a plan-only run so you can review the impact before merging. See [Managing Configuration on Git](https://bluebricks.co/docs/workflows/bluebricks-git-repository-guide/managing-configuration-on-git) for details on the manifest file format.

You can also target an existing environment through the Bluebricks app or CLI. In the app, select the environment from the **Environments** page and click **Deploy**. In the CLI, use the `--env-slug` flag to target the correct environment:

```bash
bricks install web-stack --collection=production --env-slug=web-stack-prod
```

## What happens at the cloud provider level

When Bluebricks applies a change, the underlying IaC engine translates input changes into cloud API calls. The behavior depends on the resource type and cloud provider:

* **In-place updates**: most compute and configuration changes (VM size, node count, scaling settings) are applied without replacing the resource
* **Replace (destroy + recreate)**: some changes require a full resource replacement (e.g., changing a disk type that the provider does not support modifying in-place)
* **No-op**: if the new input values match the current state, the plan shows no changes

The run plan always shows the exact operations before they execute, so you can review whether a change is in-place or requires replacement.

{% hint style="warning" %}
Some changes cause downtime. Review the plan output carefully, especially for production environments. If a resource shows `destroy` then `create`, expect a brief interruption.
{% endhint %}