Core 03 · Cloud Provisioning

Guardrails for cluster operations — scheduled, scoped, and audited.

Guardrails automate the operations you'd otherwise do by hand. Target environments or clusters by filter, pick an action — scale up, scale down, or destroy — and choose when it runs. Scoped to exactly what matches, governed by your permissions, and logged on every run.

  • Scale & teardown
  • Filter-scoped
  • Audited every run
Scale non-prod down nightly Active
1 Target
Environments
2 Filter
env-typeisdevelopment
andnamespacecontainsstaging
3 Action
Env Scale Down
4 Schedule
SMTWTFS at 20:00 · weekly
Anatomy of a guardrail

Target, filter, action, schedule

A guardrail reads like a sentence: take this action on the resources that match these filters, on this schedule. Four parts express almost any routine operation you run today by hand.

1 · Target
ModuleEnvironments or clusters
2 · Filter
Match by attributeis · is not · contains · labels
3 · Action
What to doscale up · scale down · destroy
4 · Schedule
When it runsonce · weekly · monthly
What you can automate

Six actions, scheduled and scoped

Each guardrail runs one action against the targets your filter matches — nothing more. Compose a handful and your weekends, nights, and ephemeral environments take care of themselves.

Env Scale Up

Bring development and staging environments back up before the workday — ready when the team logs in.

Env Scale Down

Spin non-prod down at night and on weekends — the single biggest lever on idle Kubernetes spend.

Environment Destroy

Tear down ephemeral and preview environments on a cadence — so abandoned ones never linger and bill.

Cluster Destroy

Decommission clusters that match a filter on schedule — clean teardown for short-lived or test clusters.

Nodegroup Scale Up

Add capacity to a cluster's node groups ahead of a known peak — batch jobs, launches, business hours.

Nodegroup Scale Down

Shrink node groups when demand drops — Karpenter and managed node groups handled in the right order.

A week on autopilot

Set it once — it runs on its own

Schedule a guardrail to run once, every few weeks on chosen weekdays, or monthly. Here's a single week of non-prod following the rules above.

MON
07:00Scale up dev
20:00Scale down
TUE
07:00Scale up dev
20:00Scale down
WED
07:00Scale up dev
20:00Scale down
THU
07:00Scale up dev
20:00Scale down
FRI
07:00Scale up dev
19:00Destroy preview envs
SAT
SUN
22:00Nodegroup scale down
Scoped, governed, audited

Automation you can trust with destroy

A scheduled action that can scale or tear down resources has to be safe by construction. Guardrails are — scoped to exactly what your filter matches, run under your permissions, and recorded every time.

Scoped by filter — preview the matches

Before it's saved, you see exactly which environments or clusters the filter resolves to. The action only ever touches that set — never a stray match.

Runs under your permissions

Scheduled runs execute as an Atmosly service identity bound by the same RBAC as a person — a guardrail can never do what its owner couldn't.

Every run is audited

Each execution records what matched, the action taken, and the result — with notifications on scale and teardown, so a scheduled change is never a silent one.

Scale is reversible

Scale-down restores on the next scale-up; destroy targets only the ephemeral, filter-matched resources it's meant to. Pause or disable any guardrail at any time.

The payoff

Idle spend gone, by Monday morning

Nights & weekends
non-prod scaled down while no one's using it
Zero lingering
ephemeral environments torn down on a cadence
Filter-scoped
only what matches is ever touched
Every run
logged, attributed, and reversible
Questions

What teams ask about guardrails

Isn't a scheduled "destroy" dangerous?
It's safe by construction. A guardrail only ever acts on the resources its filter matches, and you preview that exact set before saving. It runs under the owner's permissions, is fully audited, and sends notifications on every run — so teardown is deliberate and scoped, never a blanket sweep.
What can I target, and how?
Environments or clusters, matched with filters on attributes and labels using is, is not, and contains. Combine conditions to scope precisely — e.g. environment type is development and namespace contains staging.
What schedules are supported?
Run once at a set time, every few weeks on the weekdays you choose, or monthly — with a repeat interval so "every 2 weeks on Fri" or "monthly" are both a couple of clicks. The next run time is computed and shown for each guardrail.
Who runs the action, and is it logged?
A guardrail runs automatically as an Atmosly service identity, bound by the same RBAC as the person who created it — it can never exceed their access. Every run records what matched, the action, and the result, and notifies the relevant team.

Set it once. Forget it.

Connect a cluster, read-only to start. Create a guardrail, preview the resources it matches, and put your nights and weekends on autopilot — in minutes. Free, no sales call.

Create a guardrail → Book a 15-min walkthrough