Auto-shutdown for dev, staging, and test environments
Last updated: August 24, 2026 · Content reviewed quarterly
Idlefy keeps development, staging, and test VMs on AWS and Google Cloud stopped by default.
When an engineer needs a machine, they lease it for the hours they need — from Slack,
Telegram, or the web dashboard — and it stops itself when the lease expires. The stop is
the cloud's normal power-off, never a terminate: disks and the instance survive, and the
same machine starts again on the next lease. There is no agent to install — Idlefy works
through the cloud providers' own APIs, and on AWS it can only touch instances tagged
idlefy=enabled, a boundary enforced by the
IAM policy itself. Nobody has to remember to turn anything off, so the classic failure
mode of dev infrastructure — the box someone forgot on Friday, billing quietly through the
weekend — stops being possible.
The forgotten-VM tax
A development or staging machine is typically needed during working hours — call it ten hours a day, five days a week. Left running 24/7, up to ~70% of the hours it bills for fall outside that window: nights, weekends, the sprint when nobody touched it. The bill does not distinguish a machine doing useful work from one that is merely on.
Schedulers and cleanup scripts exist for this, and they share a weakness: they act on a machine that is on by default. Every gap — an environment outside the schedule, a script that broke, a box spun up for a demo and never registered — leaks money until a person notices. Idlefy inverts the default instead.
Stopped is the default
A managed VM stays stopped until someone takes a lease — a fixed booking of an hour, a workday, or up to 72 hours on Pro. The machine starts in about a minute, runs for exactly the booked time, and stops itself at expiry. Warnings go out 20 and 5 minutes before the stop, and extending is one tap from the same chat.
Mid-debug when the lease runs out? On the Pro plan, the Safety System grants a single 30-minute grace period when the machine still looks in use and you haven't responded — a missed notification doesn't kill a build. Activity can postpone the stop by that one window; it can never cancel it. Compute billing stops while the machine is off; disk storage continues at the provider's normal rate.
On AWS the access boundary — only instances tagged
idlefy=enabled — is enforced by the IAM
policy itself. On Google Cloud the same boundary is enforced in Idlefy's application
layer rather than by IAM, an honest difference the
how-it-works page
documents along with the full lease lifecycle.
How is this different from AWS Instance Scheduler or a DIY script?
Instance Scheduler on AWS is a solid official solution, and a Lambda-plus-EventBridge script is a fine weekend project. Both automate a calendar. If you're weighing Idlefy as an AWS Instance Scheduler alternative, the differences show up in who maintains it and what happens outside the schedule:
| Idlefy lease | Instance Scheduler on AWS | DIY Lambda / cron | |
|---|---|---|---|
| Setup | Connect a cloud account (keyless OIDC, a few minutes), tag instances | CloudFormation deployment; schedules and periods defined in DynamoDB | You write, deploy, and wire it yourself |
| Ongoing maintenance | None on your side | Your team owns the stack, its updates, and its tag hygiene | Yours forever; breaks silently when clouds change |
| Clouds covered | AWS and Google Cloud, one workflow | AWS only | One script per cloud |
| Working outside the schedule | There is no schedule — you lease exactly the hours you need, any hours | Edit the schedule, or the machine stops at the configured hour | Ask whoever owns the script |
| Self-service for engineers | Start and extend from Slack, Telegram, or web | Via tags and schedule config — an ops task | Usually not |
| Cost | Free plan available; see pricing | Free solution; you pay the underlying AWS resources it runs on | Free, except the engineering time |
The structural difference is the default. A scheduler turns machines off at certain hours; everything it doesn't cover stays on. A lease model keeps machines off unless someone is actively holding them — the failure mode disappears instead of shrinking.
What a workday schedule looks like in dollars
List-price math for common dev instance types: the same machine running 24/7 versus only during a 10×5 work week.
| Instance | Running 24/7 | Workday schedule (10×5) | Difference |
|---|---|---|---|
| t3.large AWS | $61/mo | $18/mo | −$43/mo est. |
| m5.xlarge AWS | $140/mo | $42/mo | −$98/mo est. |
| c5.xlarge AWS | $124/mo | $37/mo | −$87/mo est. |
| e2-standard-4 Google Cloud | $98/mo | $29/mo | −$69/mo est. |
| n2-standard-8 Google Cloud | $284/mo | $84/mo | −$199/mo est. |
On-demand list prices, cheapest listed region. Prices as of 2026-08-31. Estimates only — your regions, usage, and discounts will differ. Per-type detail lives on the instance idle-cost pages.
Run your own numbers
Pick your instance type and weekly hours — the calculator prices the schedule against 24/7 from the same list-price snapshot. No signup.
This is a list-price estimate. The free Idle Audit reads 30 days of your real usage and prices every idle hour.
Run a free idle auditMade for how teams actually work
Leases start where your team already lives: a tap in the Slack App Home, a message to the Telegram bot, or one click in the web dashboard. Nobody opens a cloud console to get a staging box for the afternoon.
Every lease is recorded — who started which machine, when, and for how long — so “why was this running all weekend?” has an answer. Role-based access on Basic and Pro controls who can manage which machines, and one organization can span multiple AWS accounts and GCP projects.
For a real-world account of what this looks like in practice, read the case study: how one team cut up to 67% of dev VM spend by flipping the default to off.
Common questions
Do stopped EC2 instances cost money?
A stopped instance is not charged for compute — the per-hour instance charge ends with the stop. Attached EBS volumes keep billing for storage at the normal rate, and a reserved Elastic IP left unattached bills too. The same shape holds on Google Cloud: no compute charge while stopped, persistent disks continue to bill.
Can I schedule Google Cloud VMs to stop automatically?
Yes — Google Cloud has native instance schedules (a resource policy with fixed start/stop times), and AWS has Instance Scheduler. Both automate a calendar you configure up front. Idlefy replaces the calendar with a lease: the machine is off by default, and each engineer books exactly the hours they need, from chat, without anyone editing a schedule.
How much can shutting down dev environments after hours save?
It depends on your usage, but the arithmetic is stark: a 10×5 work week uses 50 of the week's 168 hours, so a machine that runs 24/7 bills up to ~70% of its hours outside working time. The free Idle Audit reads 30 days of your actual usage and turns that estimate into your own number.
What is the difference between stopping and terminating an instance?
Stopping is the cloud's normal power-off: the instance keeps its ID, disks, and configuration, and can start again later. Terminating deletes the instance permanently. A lease expiry in Idlefy always performs a stop, never a terminate — your environment is exactly where you left it on the next lease.
Can auto-shutdown interrupt a build or a debug session?
Not silently. Warnings arrive 20 and 5 minutes before expiry — in Slack, Telegram, and the web dashboard — and extending is one tap from any of them. On the Pro plan, the Safety System adds a single 30-minute grace period when the machine still looks in use and you haven't responded. The stop time itself is always the lease you set, never a guess.
More edge cases are covered in the FAQ.
Measure your dev environments first
The free Idle Audit reads 30 days of usage across your fleet and prices every idle hour — before you change anything. Read-only, no plan required.
Run a free idle auditRunning GPU machines too? See auto-shutdown for GPU instances, or compare plans on the pricing page.