Managing Storage

Resize disks, change disk types, and manage storage for deployed environments by updating blueprint inputs

Overview

Storage changes include resizing disks, changing disk types, and adding new volumes. Like other Day 2 operations, you update the relevant blueprint inputs and start a new run of the environment. However, storage changes have important constraints: some modifications are in-place, while others require resource replacement.

Prerequisites

• An existing environment with a completed run

• The blueprint exposes inputs for storage properties (e.g., disk_size_gb, storage_type, disk_sku)

• Access to the collection that the environment belongs to

How to update storage

Git

Update the storage-related input in your environment manifest file and push the change. If you use GitOps environments, Bluebricks triggers a plan automatically. Review the plan carefully for any destroy + create operations before merging.

# environment manifest (e.g., data-layer-prod.yaml)
inputs:
  disk_size_gb: 256

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 storage-related input values (e.g., change disk_size_gb from 128 to 256)

4. Review the plan carefully for any destroy + create operations

5. Click Deploy

CLI

bricks install data-layer \
  --collection=production \
  --env-slug=data-layer-prod \
  --props '{"disk_size_gb": 256}'

Always preview first with --plan-only:

bricks install data-layer \
  --collection=production \
  --env-slug=data-layer-prod \
  --props '{"disk_size_gb": 256}' \
  --plan-only

Common storage changes

Increase disk size

Increasing disk size is generally safe and applied in-place by most cloud providers. The underlying volume expands without data loss.

Cloud provider	Typical input	Example change
Azure	disk_size_gb	128 to 256
AWS	volume_size	100 to 200
GCP	disk_size_gb	50 to 100

Disk size can only be increased, not decreased. If you need a smaller disk, you must create a new volume and migrate data.

Change disk type

Switching between disk performance tiers (e.g., Standard HDD to Premium SSD) changes the IOPS and throughput profile of the volume.

bricks install data-layer \
  --collection=production \
  --env-slug=data-layer-prod \
  --props '{"storage_account_type": "Premium_LRS"}'

Some disk type changes require resource replacement depending on the cloud provider and IaC resource definition. Always run with --plan-only first and check whether the plan shows an in-place update or a destroy/create cycle.

Add additional volumes

If the blueprint supports multiple volumes (e.g., a data_disks list input), you can add new disks by updating the input:

bricks install data-layer \
  --collection=production \
  --env-slug=data-layer-prod \
  --props-file=./storage-config.json

Example storage-config.json

{
  "data_disks": [
    { "name": "data-01", "size_gb": 256, "type": "Premium_LRS" },
    { "name": "data-02", "size_gb": 512, "type": "Premium_LRS" }
  ]
}

Constraints and caveats

Storage changes carry more risk than compute scaling because they can involve data. Keep these constraints in mind:

• Shrinking disks is not supported by most cloud providers. You must create a new volume and migrate data manually

• Disk type changes may require replacement: if the IaC resource does not support in-place type changes, the plan will show a destroy + create cycle. This means data loss unless you have backups

• OS disks vs data disks: changing the OS disk often requires VM replacement. Data disk changes are usually independent

• Filesystem expansion: increasing disk size at the cloud layer does not automatically expand the filesystem. Your application or startup scripts must handle partition and filesystem resizing

If the plan shows a destroy operation on a storage resource, stop and verify that you have backups before proceeding. Destroyed disks cannot be recovered.

Cloud provider behavior

Storage change behavior varies by provider. Size increases are generally safe and online, but type changes and shrinking have significant constraints.

Azure Managed Disks

• Disk size increases are in-place but may require the VM to be deallocated

• Changing between Standard HDD, Standard SSD, and Premium SSD is supported in-place for most configurations

• Ultra Disk changes have additional constraints around availability zones

AWS EBS

• Volume size increases are applied online (no downtime) for most volume types

• Volume type changes (e.g., gp2 to gp3) are applied in-place

• IOPS and throughput modifications for gp3 and io1/io2 volumes are in-place

• After resizing, the OS must extend the filesystem (resize2fs or xfs_growfs)

GCP Persistent Disks

• Disk size increases are online and do not require VM downtime

• Switching between pd-standard, pd-balanced, and pd-ssd requires creating a new disk

• Regional persistent disks have additional replication constraints

What to check after storage changes

1. Run status: confirm the run completed successfully

2. Disk state: verify the new size and type in your cloud provider console

3. Filesystem: confirm the OS-level filesystem reflects the new disk size

4. Application health: check that databases and storage-dependent services are operating correctly

5. Backups: verify your backup schedule covers the updated volumes