Scaling Compute Resources

Update CPU, memory, and VM sizes for deployed workloads by changing blueprint inputs and re-running environments

Overview

Scaling compute resources (CPU, memory, VM size) is one of the most common Day 2 operations. In Bluebricks, you change the relevant blueprint input values and start a new run of the environment. The underlying IaC engine handles the cloud provider API calls to resize or reconfigure your resources.

Ask the agent. Scale resources directly, for example: "Scale the EKS cluster in prod-eu to 5 nodes." See Agent Overview.

Prerequisites

• An existing environment 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 that the environment belongs to

How to scale compute resources

Git

Update the compute-related input in your environment manifest file and push the change. If you use GitOps environments, Bluebricks triggers a plan automatically. For PR-based workflows, the plan posts to your pull request for review before merging.

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

See Managing Configuration on Git for the full manifest format.

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

CLI

Pass the updated input values using --props or --props-file:

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

Or use a properties file:

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:

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

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:

Cloud provider	Typical input	Example change
Azure	vm_size	Standard_D2s_v3 to Standard_D4s_v3
AWS	instance_type	t3.medium to t3.xlarge
GCP	machine_type	e2-medium to e2-standard-4

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.

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:

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

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.

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.

Azure

• 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 for availability.

• Switching between VM families (e.g., D-series to F-series) is in-place but may take longer due to hardware reallocation.

AWS

• 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.

GCP

• 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.

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 is enabled, the next check should show no drift