How Idlefy works: lease-based auto-shutdown for cloud VMs

Last updated: July 21, 2026 · Content reviewed quarterly

Idlefy is a lease-based auto-shutdown platform for cloud virtual machines on AWS and Google Cloud. Managed VMs stay stopped by default. When an engineer needs one, they take a lease — a fixed booking of an hour, a workday, or up to 72 hours on Pro — from Slack, Telegram, or the web dashboard, and the machine starts in about a minute. When the lease expires, Idlefy stops the VM automatically: the shutdown is executed by the platform, but the timer is always set by a person. Idlefy never infers a shutdown time from how busy a machine looks. Warnings go out 20 and 5 minutes before expiry, and a lease can be extended from the same chat at any time. Stopped machines keep their persistent disks, and on AWS Idlefy can only touch instances tagged idlefy=enabled — a boundary written into the IAM policy itself.

What is a lease?

A lease is a fixed-length booking of one virtual machine by one person. Booking a dev box for four hours means: the VM starts now, runs for four hours, and stops itself at the end — unless you extend it. Leases are how machines get turned on in everyday use. Without an active lease, a managed VM stays stopped — the machine someone forgot to turn off, burning money over the weekend, stops being your default failure mode.

You start a lease wherever your team already lives — a tap in the Slack App Home, a message to the Telegram bot, or one click in the web dashboard. Extending works the same way, from the same place, while the lease is running. Every lease is recorded — who started which machine, when, and for how long — so the audit trail comes free.

One day of vm-gpu-01 UTC

vm-gpu-01 4h Start ▸ from Slack, Telegram, or Web

RUNNING 4h

00:0006:0012:0018:0024:00

09:00lease started— @anna, 4h via Slack

12:40warning sent— 20 min left, extend?

13:00auto-stop— lease expired, disks kept

13:01billing: 4h paid, 20h free

What happens when a lease expires?

Nothing about the stop is a surprise. Idlefy sends a warning 20 minutes before expiry and another at 5 minutes — to every channel you have connected: Slack, Telegram, and the web dashboard. Extend from any of them and the timer moves; work continues.

If the lease runs out: on the Pro plan, the Safety System checks whether the machine still looks actively in use. If it does and you haven't responded, it grants a single 30-minute grace period and notifies you again — built for the moments you're on lost wifi or away from the keyboard mid-deploy. Activity can postpone the stop by that one grace window; it can never cancel it. On Free and Basic there is no grace window: the VM is stopped shortly after expiry.

Either way the machine is stopped, not terminated — see what survives below. Edge cases are covered in the FAQ.

What survives a stop?

A lease expiry performs a stop — the cloud provider's normal power-off — never a terminate. What that means for your data:

Resource	After a stop
Root and attached persistent disks (EBS, GCP persistent disks)	Preserved. Files, packages, and checkouts are there on the next start.
The instance itself (ID, type, tags)	Preserved — the same machine starts again, not a new one. A non-static public IP may change across a stop/start; that is the cloud's behavior, not Idlefy's.
Memory and running processes	Gone — a stop is a power-off. Save your work; tmux sessions do not survive.
Local instance-store / local-SSD scratch disks	Not preserved. Several GPU families — g4dn, g5, g6, p4d — carry these; sync anything on scratch off the machine before the lease ends.

Compute billing stops with the machine; disk storage continues to bill at the provider's normal rate while the VM is off. Per-type running costs are on the instance idle-cost pages.

How does Idlefy access my cloud?

Through the cloud provider's own APIs — there is no agent to install on your machines. Authentication is keyless by default: OIDC federation on AWS (Web Identity Federation) and Workload Identity Federation on GCP. With this default setup no long-lived access keys are stored anywhere, and revoking the trust in your own console ends access immediately. (A legacy encrypted-key mode exists for older accounts; it is not recommended.)

What Idlefy is allowed to do is deliberately lopsided. Read access covers the whole account — that is what lets the free Idle Audit price your entire fleet. Write access — start, stop, reboot — is conditioned on the idlefy=enabled tag. On AWS that condition lives in the IAM policy itself, so it is enforced by AWS, not by our good behavior — you can read it in your own console. On Google Cloud, IAM cannot scope these actions by label, so the boundary lives in Idlefy's application layer instead: a VM joins management only if it carries the label when Idlefy discovers it, and you can disable any machine in the dashboard at any time. That is a software check on our side, not a policy your cloud enforces — an honest difference worth knowing.

AWS policy — simplified excerpt Tag-scoped

{
  "Statement": [
    {
      "Sid": "IdlefyCore",
      "Effect": "Allow",
      "Action": [
        "ec2:DescribeInstances",
        "ec2:DescribeTags",
        "ec2:DescribeInstanceTypes",
        "ec2:DescribeRegions"
      ],
      "Resource": "*"
    },
    {
      "Sid": "IdlefyVMManagement",
      "Effect": "Allow",
      "Action": [
        "ec2:StartInstances",
        "ec2:StopInstances",
        "ec2:RebootInstances"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": { "ec2:ResourceTag/idlefy": "enabled" }
      }
    }
  ]
}

Simplified excerpt — the recommended policy also includes read-only metrics access, pricing lookup, and a legacy capitalized tag spelling. The full JSON is shown during setup.

How is this different from cron schedulers and idle detectors?

Three kinds of tools can turn a VM off. The difference is who decides when.

	Idlefy lease	Cron scheduler	Idle detector
Who sets the stop time	The person using the machine, per lease	A fixed calendar, set once	An algorithm's inference
Working late	Extend from chat in one tap	Stops at the scheduled hour anyway	Depends on whether you look active to it
Forgot to stop a machine	Can't happen — stopped is the default	Off at the next scheduled window	Stopped once it decides you're idle
Mid-task stop risk	Warned at 20 and 5 minutes; on Pro the Safety System can grant one 30-minute grace	No check — the schedule fires	A quiet-looking build can be stopped mid-run
Starting again	Chat or web, about a minute	Wait for the window, or the cloud console	Usually the cloud console

Idlefy ships idle notifications too — on Pro, it can flag a machine that looks unused and ask whether to stop it, with one-tap stop and snooze buttons. The notification asks; it never acts on its own. Shutdown authority stays with the lease timer your team set.

See your own waste 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 audit

Prefer raw numbers? Try the schedule savings calculator, or see what each plan includes on the pricing page.