Temporary Scaling

Scale infrastructure temporarily for testing or load evaluation, then revert or promote the change using Bluebricks environments

Overview

Sometimes you need to scale infrastructure for a limited period: a load test, a proof of concept, or a short-term capacity increase. Bluebricks supports this through its standard environment workflow. Scale up by updating inputs and starting a new run, evaluate the result, then either revert to the original configuration or promote the change to other collections.

When to use temporary scaling

• Load testing: increase compute or node count for a 2-7 day test, then revert

• POC evaluation: provision larger resources to validate a new workload, then decide whether to keep or discard

• Seasonal demand: scale up for a known traffic spike, then scale back down

• Pre-production validation: test a configuration change in staging before promoting to production

The temporary scaling workflow

1

Record current input values

Before making changes, note the current input values so you can revert later. You can find them in the environment's latest run details or in your Git-managed manifest file.

If you use Git-managed manifests, your current configuration is already versioned. You can revert by reverting the Git commit.

2

Scale up

Update the inputs and start a new run. If you use GitOps environments or Git-managed manifests, create a feature branch with the scaled-up configuration and push it:

# environment manifest (e.g., k8s-staging.yaml)
inputs:
  node_count: 10

Bluebricks triggers a plan on the PR so you can review the change before merging. You can also scale up through the Bluebricks app or CLI:

bricks install k8s-platform \
  --collection=staging \
  --env-slug=k8s-staging \
  --props '{"node_count": 10}'

3

Evaluate

Run your load test, POC, or validation. Monitor resource usage, application performance, and cost.

4

Decide: promote or revert

To promote the change to another collection (e.g., staging to production), use the promotion workflow. Promotion copies the blueprint version and input values from one collection to another, then starts a new run in the target environment.

To revert, restore the original input values and start a new run. With Git, revert the commit or close the PR. With the CLI:

bricks install k8s-platform \
  --collection=staging \
  --env-slug=k8s-staging \
  --props '{"node_count": 5}'

Using Git for temporary changes

When using Git-managed manifests or GitOps environments, temporary scaling fits naturally into a branch-based workflow:

1. Create a feature branch with the scaled-up configuration

2. Push the branch to trigger a deployment to a development or staging environment

3. Evaluate the scaled configuration

4. Merge to main if you want to keep the change, or close the PR to discard it

This gives you a full audit trail of temporary changes and easy rollback through Git history.

Combining with TTL for automatic cleanup

For environments that should only exist for a limited time, combine temporary scaling with Time to Live (TTL). TTL schedules automatic uninstallation of the environment, so you do not need to remember to tear it down manually.

This is particularly useful for:

• Dedicated test environments: deploy a scaled-up environment for a load test, set a TTL to uninstall it after 3 days

• Sandbox environments: give engineers temporary access to larger resources with an automatic cleanup schedule

• Cost control: prevent temporarily scaled environments from running indefinitely

TTL uninstalls the environment (destroys resources) but preserves the environment record and configuration. You can re-run it later if needed.

Best practices

• Always record baseline values before scaling so you can revert precisely

• Use --plan-only before applying changes to preview the impact

• Set a TTL on temporary environments to avoid forgotten resources accumulating cost

• Use separate collections for temporary testing to isolate changes from production workloads. Collection properties keep configuration consistent within each collection

• Review cost implications before scaling: larger VMs, more nodes, and premium storage tiers increase spend immediately

• Promote only validated changes to production. Use the promotion workflow to carry forward proven configuration