# Scaling Compute Resources

## Overview

Scaling compute resources (CPU, memory, VM size) is one of the most common [Day 2 operations](https://bluebricks.co/docs/managing-infrastructure/managing-infrastructure). In Bluebricks, you change the relevant [blueprint](https://bluebricks.co/docs/core-concepts/packages/blueprints-overview) input values and start a new run of the [environment](https://bluebricks.co/docs/core-concepts/environments). The underlying IaC engine handles the cloud provider API calls to resize or reconfigure your resources.

## Prerequisites

* An existing [environment](https://bluebricks.co/docs/core-concepts/environments) with a completed run
* The blueprint exposes inputs for the compute properties you want to change (e.g., `vm_size`, `instance_type`, `cpu_cores`, `memory_gb`)
* Access to the [collection](https://bluebricks.co/docs/core-concepts/collections) that the environment belongs to

## How to scale compute resources

{% tabs %}
{% tab title="Git" %}
Update the compute-related input in your environment manifest file and push the change. If you use [GitOps environments](https://bluebricks.co/docs/core-concepts/environments/gitops-environments), Bluebricks triggers a plan automatically. For PR-based workflows, the plan posts to your pull request for review before merging.

```yaml
# environment manifest (e.g., web-app-prod.yaml)
inputs:
  vm_size: "Standard_D4s_v3"
```

See [Managing Configuration on Git](https://bluebricks.co/docs/workflows/bluebricks-git-repository-guide/managing-configuration-on-git) for the full manifest format.
{% endtab %}

{% tab title="Bluebricks app" %}

1. Open the **Environments** page and go to the environment you want to update
2. In the three-dot menu click **Deploy**
3. Update the compute-related input values (e.g., change `vm_size` from `Standard_D2s_v3` to `Standard_D4s_v3`)
4. Review the plan to confirm the change is in-place
5. Click **Deploy**
   {% endtab %}

{% tab title="CLI" %}
Pass the updated input values using `--props` or `--props-file`:

```bash
bricks install web-app \
  --collection=production \
  --env-slug=web-app-prod \
  --props '{"vm_size": "Standard_D4s_v3"}'
```

Or use a properties file:

```bash
bricks install web-app \
  --collection=production \
  --env-slug=web-app-prod \
  --props-file=./updated-props.json
```

Add `--plan-only` first to preview the change without applying it:

```bash
bricks install web-app \
  --collection=production \
  --env-slug=web-app-prod \
  --props '{"vm_size": "Standard_D4s_v3"}' \
  --plan-only
```

{% endtab %}
{% endtabs %}

## Common compute changes

### Increase CPU or memory

Most cloud providers bundle CPU and memory into instance or VM sizes. To scale up, change the VM size input to a larger tier:

<table><thead><tr><th width="148.8359375">Cloud provider</th><th width="173.1484375">Typical input</th><th>Example change</th></tr></thead><tbody><tr><td>Azure</td><td><code>vm_size</code></td><td><code>Standard_D2s_v3</code> to <code>Standard_D4s_v3</code></td></tr><tr><td>AWS</td><td><code>instance_type</code></td><td><code>t3.medium</code> to <code>t3.xlarge</code></td></tr><tr><td>GCP</td><td><code>machine_type</code></td><td><code>e2-medium</code> to <code>e2-standard-4</code></td></tr></tbody></table>

{% hint style="info" %}
The exact input name depends on how the blueprint author defined the inputs. Check the blueprint's input definitions using `bricks blueprint describe <blueprint>` or in the Bluebricks app under the blueprint details page.
{% endhint %}

### Change VM series or family

Switching between VM families (e.g., from general-purpose to compute-optimized) follows the same workflow. Update the VM size input to the new family:

```bash
bricks install web-app \
  --collection=production \
  --env-slug=web-app-prod \
  --props '{"vm_size": "Standard_F4s_v2"}'
```

{% hint style="warning" %}
Changing VM families may cause a brief restart. The plan output indicates whether the change is in-place or requires replacement. Review it before approving.
{% endhint %}

## Cloud provider behavior

How a compute change is applied depends on the cloud provider. Most resize operations require a brief stop/start cycle but preserve attached storage and network configuration.

<details>

<summary>Azure</summary>

* VM resizing is typically in-place. Azure stops the VM, resizes it, and restarts it. Expect a brief interruption.
* Not all VM sizes are available in every region. Check [Azure VM sizes](https://learn.microsoft.com/en-us/azure/virtual-machines/sizes) for availability.
* Switching between VM families (e.g., D-series to F-series) is in-place but may take longer due to hardware reallocation.

</details>

<details>

<summary>AWS</summary>

* EC2 instance type changes require a stop/start cycle. The instance retains its private IP and attached EBS volumes.
* Changing instance families (e.g., `t3` to `c6i`) follows the same stop/start pattern but may fail if the new type is not available in the current Availability Zone.
* For Auto Scaling Groups, the launch template updates immediately but existing instances retain their current type until replaced by a scaling event or instance refresh.

</details>

<details>

<summary>GCP</summary>

* Machine type changes require a VM stop/start. Persistent disks remain attached.
* Custom machine types allow independent CPU and memory scaling.
* Switching between machine families (e.g., `e2` to `n2`) follows the same stop/start workflow.

</details>

## What to check after scaling

1. **Run status**: confirm the run completed successfully in the environment's run history
2. **Resource state**: verify the new compute configuration in your cloud provider console
3. **Application health**: check that your workloads are running correctly after the resize
4. **Drift detection**: if [drift detection](https://bluebricks.co/docs/core-concepts/environments/drift-detection) is enabled, the next check should show no drift