# Temporary Scaling

## 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](https://bluebricks.co/docs/core-concepts/environments) 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

{% @mermaid/diagram content="flowchart LR
A\[Current state] --> B\[Update inputs]
B --> C\[Start new run]
C --> D\[Evaluate]
D -->|Keep| E\[Promote to production]
D -->|Revert| F\[Restore original inputs]
F --> G\[Start new run]" %}

{% stepper %}
{% step %}
**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.

{% hint style="success" %}
If you use [Git-managed manifests](https://bluebricks.co/docs/workflows/bluebricks-git-repository-guide/managing-configuration-on-git), your current configuration is already versioned. You can revert by reverting the Git commit.
{% endhint %}
{% endstep %}

{% step %}
**Scale up**

Update the inputs and start a new run. If you use [GitOps environments](https://bluebricks.co/docs/core-concepts/environments/gitops-environments) or [Git-managed manifests](https://bluebricks.co/docs/workflows/bluebricks-git-repository-guide/managing-configuration-on-git), create a feature branch with the scaled-up configuration and push it:

```yaml
# 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:

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

{% endstep %}

{% step %}
**Evaluate**

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

{% step %}
**Decide: promote or revert**

**To promote the change** to another collection (e.g., staging to production), use the [promotion workflow](https://bluebricks.co/docs/core-concepts/runs/promoting-environments). 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:

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

{% endstep %}
{% endstepper %}

## Using Git for temporary changes

When using [Git-managed manifests](https://bluebricks.co/docs/workflows/bluebricks-git-repository-guide/managing-configuration-on-git) or [GitOps environments](https://bluebricks.co/docs/core-concepts/environments/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)](https://bluebricks.co/docs/core-concepts/environments/environment-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

{% hint style="info" %}
TTL uninstalls the environment (destroys resources) but preserves the environment record and configuration. You can re-run it later if needed.
{% endhint %}

## 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](https://bluebricks.co/docs/core-concepts/collections/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](https://bluebricks.co/docs/core-concepts/runs/promoting-environments) to carry forward proven configuration