# Idlefy

> Lease-based auto-shutdown for cloud VMs. A developer books a machine for a fixed duration (e.g., 1h, 8h, 24h) from Slack, Telegram, or web; the VM starts on demand and stops itself when the lease expires. The shutdown timer is set by a human and is never inferred from activity. Built for AWS and GCP dev/staging environments where servers run 24/7 but are actively used 8 hours a day. A free, read-only Idle Audit measures 30 days of actual idle waste across a whole cloud account before any commitment.

## What Idlefy is (and is not)

Idlefy automates the shutdown, not the decision of when to shut down. The differentiator vs. typical FinOps tools:

- **Auto-shutdown is the core mechanism.** Managed VMs sit stopped by default. Starting a lease starts the machine; the lease expiring stops it. Nobody has to remember to turn anything off — that is the entire product.
- **The timer is human-set, never guessed.** Idlefy does not derive a shutdown time from activity thresholds. Runtime activity can only *delay* a stop by one grace period (Pro plan, see Safety System) — it can never trigger one. This is the difference vs. threshold automation that kills a box mid-compile because it briefly looked quiet.
- **Idle notifications are suggestions, not actions.** Separately from leases, Idlefy can flag a VM that looks unused: "this looks idle — stop it?" That notification asks; it does not act.
- **Stop, not terminate.** Stopped VMs keep their EBS volumes and persistent disks, and restarting is one click in Slack/Telegram/web. Data on local instance-store or local-SSD scratch drives — which most GPU and ML instance families (the p-, g- and a-series included) commonly carry (on Google Cloud they are attached rather than built in) — does not survive a stop.
- **Access is scoped to tagged instances.** On AWS the IAM policy Idlefy asks for is conditioned on `ec2:ResourceTag/idlefy=enabled`, so untagged instances are outside what it can start or stop at the IAM level. On GCP the scoping is enforced in Idlefy's application layer rather than by IAM — a software check on Idlefy's side (only instances discovered with the label are registered as manageable), not a cloud-enforced policy.
- **Keyless cloud access by default.** Idlefy authenticates to AWS and GCP via OIDC federation — no long-lived credentials are stored. Encrypted-key storage is supported as a legacy mode but is not recommended.

This design is deliberate: regulated/enterprise teams accept a shutdown they scheduled, but not one an algorithm decided on their behalf.

## Smart Workflows — leased environments beyond a single VM

A Smart Workflow applies the same lease model to a shared environment rather than one VM. Starting the lease fires the organization's own CI pipeline (GitHub Actions or GitLab CI) to bring the environment up; lease expiry fires the teardown pipeline. Teams commonly use this to scale a Kubernetes dev/staging namespace up on lease start and back down to zero at expiry — Idlefy never talks to the cluster directly; it triggers pipelines the team already owns, on a timer a human set. Several engineers can join one workflow booking and extend it from chat, like a VM lease, and a workflow lease can run longer than a VM lease — up to 30 days on Pro. Plan capacity is in the pricing table above (Smart Workflows column).

## Idle Audit — free waste scan, no commitment

Idle Audit answers "how much am I actually wasting on idle cloud VMs?" before any decision to adopt Idlefy. It is **free on every plan, including Free — there is no feature gate**, and it requires no change to how your infrastructure runs.

- **Account-wide, not just what Idlefy manages.** The scan enumerates every instance in the connected AWS account or GCP project, including untagged ones that Idlefy has no permission to start or stop. Read APIs (`ec2:Describe*`, `GetMetricData`) are not tag-conditionable, so the audit needs **no IAM change** beyond the read access already granted at connect time.
- **Strictly read-only.** The audit never starts, stops, tags, or modifies an instance, and never writes to Idlefy's own VM management tables. It observes and reports.
- **30 days of real usage, hour by hour.** Each hour of the window is classified against actual measured usage, so the result reflects observed behavior rather than a guess from instance size or uptime. An hour with no usage data is never counted as idle — missing data is not billed as waste.
- **Autoscaled workloads are separated out.** Instances belonging to an ASG, EKS, or GKE node group are classified as autoscaled and excluded from shutdown recommendations — stopping a node the scheduler will just replace is not a saving. Headline savings count only unmanaged standalone instances. (Kubernetes environments are handled through Smart Workflows — scale-up/teardown via the team's own CI pipelines — never by stopping nodes.)
- **Output.** A report with an overview, a per-instance breakdown with estimated monthly waste, a burn map showing which hours of the week are dead, and a separate view of what Idlefy already manages. Scans can be re-run manually once per provider per hour and scoped to chosen providers; a weekly digest email (on by default, per-owner opt-out) carries the headline figure and per-provider subtotals only.
- **Access.** Organization OWNER or team ADMIN. Available at https://app.idlefy.com/idle-audit after connecting a cloud account.

The point is sequencing: measure the real waste first, then decide whether scheduled shutdown is worth adopting. The audit is useful even to teams that never buy Idlefy.

## Pricing (USD, monthly)

| Plan | Price | VMs | Smart Workflows | Users | Max session | Channels |
|---|---|---|---|---|---|---|
| **Free** | $0 | 1 | 1 | 5 | 24h | Web + AI agents (MCP) |
| **Basic** | $50/mo | 5 (+$2/day each extra) | 5 (+$1/day each extra) | 10 (+$0.10/day each extra) | 48h | Web + Slack + Telegram + AI agents (MCP) |
| **Pro** | $100/mo | 5 (+$2/day each extra) | 5 (+$1/day each extra) | 20 (+$0.10/day each extra) | 72h | Web + Slack + Telegram + AI agents (MCP) |

**Free plan:** AWS + GCP, web control, 24h max runtime, no credit card. AI agents (MCP) on every plan. Includes Idle Audit in full — the waste scan is not plan-gated.

**Basic plan:** Everything in Free + multi-channel control, custom lease duration, RBAC, force reboot, advanced analytics, multiple AWS/GCP accounts, priority support.

**Pro plan:** Everything in Basic + idle detection that finds leased machines nobody is using and nudges the person, without false alarms during real work, Safety System (described below), advanced scheduling, full analytics suite, single sign-on (described below), budgets with blocking per team and per person. Comes with $100 trial bonus.

**Enterprise:** Custom — contact for dedicated support and bespoke terms. Single sign-on is NOT an enterprise upsell: it is included in Pro at the list price above.

No contract or commitment; cancel anytime.

## Key facts

- **Cloud providers:** AWS and GCP (production). Azure: coming soon. Oracle Cloud: on the roadmap.
- **Authentication to cloud:** Keyless OIDC federation by default — no access keys or service-account JSON stored. Legacy encrypted-key mode supported but not recommended.
- **Scope of control:** On AWS, IAM-enforced via an `ec2:ResourceTag/idlefy=enabled` condition — instances without the tag cannot be started or stopped by Idlefy. On GCP, the boundary is enforced by Idlefy's application layer instead — a software check on Idlefy's side, not a cloud-enforced policy.
- **Instance types:** All EC2 / GCE families including GPU and ML instances.
- **Spot instances:** Supported.
- **Agent:** None. Idlefy controls VMs via cloud APIs — no software to install on the VM itself.
- **Data stored:** VM metadata (instance IDs, names, schedules) and user accounts. Idlefy does not access VM contents.
- **Hosting:** EU (Finland). Encrypted at rest and in transit.
- **Sign-in:** email + password or Google OAuth on every plan; on Pro, an organization can additionally connect its own OIDC identity provider (see Single sign-on below). Connecting the first cloud provider takes ~2 minutes via OIDC trust setup.
- **Revocation:** Remove the OIDC trust / IAM role at any time — Idlefy loses access immediately.
- **Multi-account:** One Idlefy org can manage multiple AWS accounts and GCP projects simultaneously.

## AI agents

- **Every plan:** people run Idlefy from Claude, Codex or any AI agent — lease and release machines, start shared environments, create dev boxes, read spend and budgets — with their own role's permissions and nothing more (see the MCP server section below).
- **Roadmap:** AI-driven cost analytics and optimization recommendations.

## Safety System (Pro)

Designed to prevent surprise shutdowns when a user is briefly offline. If a VM lease is about to expire but:

- the VM still looks actively in use, AND
- the user hasn't responded to the expiry notification

Idlefy grants a **single** 30-minute grace extension and re-notifies the user (Slack / Telegram / web). This covers cases like the user being in the subway, on lost Wi-Fi, or otherwise unable to acknowledge the notification in time — work in progress doesn't get killed by a missed notification.

If the grace period runs out without a response, or the lease has already used its one grace period, the VM is force-stopped. Activity can postpone a stop by one grace window; it cannot cancel it. Extending the lease properly (from Slack, Telegram, or web) is what keeps a machine running.

On Free and Basic plans there is no grace window — the VM is stopped shortly after the lease expires. The grace behavior above is part of the Pro plan's Safety System.

The Safety System is **not** about Idlefy's own infrastructure availability — it's about user-side connectivity to Idlefy's notification channels.

## Single sign-on (Pro)

An organization can connect its own identity provider, and its members then sign in through that provider instead of through Google or a password. Included in Pro — not sold separately, and not gated behind a sales conversation.

- **Protocol: OpenID Connect only.** Authorization code flow with PKCE; the provider's endpoints and keys are read from its `/.well-known/openid-configuration` discovery document. **Okta** and **Auth0** are the two tested end to end against a live tenant. Another IdP is compatible if it publishes OIDC discovery, signs ID tokens with **RS256, RS512 or ES256**, and authenticates with a client secret (`client_secret_basic` or `client_secret_post`) — a provider configured for PS256, EdDSA or `private_key_jwt` is not supported today. **SAML is not supported, and neither is SCIM directory sync** — if a buyer requires either, Idlefy does not meet that requirement today.
- **Domain ownership is proven, not claimed.** An organization adds an email domain and proves control of it with a DNS TXT record; until that record resolves, the domain grants nothing. Matching is exact-label — verifying `acme.com` says nothing about `eng.acme.com`. Verification is re-checked daily, and a domain whose record disappears loses its verified status.
- **Just-in-time provisioning.** A first-time user arriving from a verified domain gets an account created on the spot — always as a regular member, on the team the admin picked, up to a cap the admin sets. SSO never grants organization ownership. JIT can be switched off, in which case only existing members can sign in.
- **Optional enforcement.** Once at least one sign-in has succeeded, an owner can require SSO. Members whose email sits on a verified domain then lose password and Google sign-in. Organization owners are deliberately exempt — a misconfigured or unreachable IdP must not lock an organization out of its own account.
- **Self-service setup.** Configured by the organization owner in the web app under Organization: issuer URL, client ID, client secret. No onboarding call, no per-connection fee.

## Channels

- **Web app:** https://app.idlefy.com (sign-up, dashboard, analytics)
- **Slack bot:** Install from in-app integrations; lease/extend/stop via the App Home dashboard and interactive buttons.
- **Telegram bot:** Same lease/extend/stop UX, edit-in-place message pattern.
- **AI assistants (every plan):** a remote MCP server at https://mcp.idlefy.com/mcp/ (see below).

## Dev Boxes (AWS)

A dev box is a personal development machine that Idlefy creates in the customer's own AWS account. It is created stopped, starts when someone leases it, and stops itself when the lease ends — the same lease model as every other managed VM.

- **Setup (organization owner, once):** turn Dev Boxes on for the organization, connect the AWS account keylessly, choose the allowed regions, exact machine types and largest disk, accept the Dev Boxes terms, and create the provisioning CloudFormation stack in the AWS console.
- **Create:** a four-step wizard — where and how big (presets for solo, team and GPU work, or any allowed type), details (name, OS, public SSH keys, optional auto-delete), who can reach it (access rules; SSH from the creator's IP by default), review. Linux only: Ubuntu, Debian, Amazon Linux, Ubuntu with the NVIDIA driver, or the organization's own images.
- **Billing:** the machine is billed by AWS to the customer's account; Idlefy has no separate dev-box fee. A stopped box still costs its disk. On Free and Basic one dev box is included; each dev box takes a slot of the plan's VM limit, and a slot past the included VMs is billed at the extra-VM rate.
- **Change size:** a stopped box with no lease can change its machine type in seconds; the disk stays.
- **Security:** Idlefy has no access inside the machine; only public SSH keys go onto it; every disk is encrypted; Idlefy can change only resources it created; every action shows in the customer's CloudTrail.
- **Not included:** backups or snapshots (deleting a box deletes its disk), Spot instances, Windows, GCP.

## Budgets

Monthly spend limits in US dollars on Idlefy's estimate of lease time and dev box disks at list prices — not the cloud bill. Set by an organization owner on the whole organization (all plans, with alerts to owners), and on Pro also per team, per member and per person, with optional blocking: when a blocking budget is used up, new leases and new dev boxes it covers are refused. Running leases are never stopped by a budget.

## AI assistants — MCP server (every plan)

Included on Free, Basic and Pro. Each action still follows the organization's plan (for example, per-team and per-person budgets need Pro) and the person's role.

Idlefy runs a remote Model Context Protocol server, so an AI assistant that supports remote MCP servers with OAuth sign-in (Claude Code, Claude, Cursor and Codex, among others) can work with Idlefy on a person's behalf: list the VMs they may use, lease, extend and release, start or join a Smart Workflow, create a dev box, read budgets and analytics, and — for an organization owner — connect a cloud account, set budgets and create teams.

- **Address:** `https://mcp.idlefy.com/mcp/` (Streamable HTTP; protocol 2026-07-28 and 2025-11-25 and earlier). Sign-in is OAuth 2.1 with a consent page in the browser, no API key; the assistant never sees a password or a cloud credential.
- **Setup:**
  - Claude Code: `claude mcp add --transport http idlefy https://mcp.idlefy.com/mcp/`
  - Claude: Open Customize → Connectors. Choose Add, then Add custom connector (in some versions: Custom → Web). Name it Idlefy, paste https://mcp.idlefy.com/mcp/ as the server URL and choose Continue. Keep the detected sign-in settings (Sign in now; OAuth client: Use Claude's published identity) and choose Continue. Choose Add, then sign in to Idlefy in the browser window that opens. (Claude desktop app or claude.ai. On Team or Enterprise, an organization owner adds it first (Organization settings → Connectors); you then choose Connect)
  - Cursor: `{"mcpServers":{"idlefy":{"url":"https://mcp.idlefy.com/mcp/"}}}` (Add to ~/.cursor/mcp.json, then reload Cursor)
  - Codex: `codex mcp add idlefy --url https://mcp.idlefy.com/mcp/`, then `codex mcp login idlefy`
- **The assistant acts as the person, never with more.** Three access levels follow the person's role, and role and membership are re-checked on every request: a member leases machines, uses Smart Workflows and their own dev boxes; a team lead also sees spend, usage and the idle audit, invites people and manages machine access for their team; an organization owner also connects cloud accounts, sets budgets, creates teams and changes roles.
- **No access inside a VM.** There is no tool that runs a command or reads a file on a machine — Idlefy itself has no such access.
- **Destructive actions need a human yes.** The server instructs the assistant to get explicit confirmation before stopping a machine in use, releasing a lease, deleting a dev box or removing a member; deleting a dev box also requires the box's exact name. Actions that cost money or cannot be undone are rate-limited per person or per organization.
- **Not available through an assistant:** billing and plan changes, single sign-on, passwords and account linking, connecting Telegram or Slack, typing secret values, and accepting the Dev Boxes terms.
- **Details:** https://idlefy.com/mcp-server/

## Documentation and discovery

- [Homepage](https://idlefy.com/): product overview and savings calculator
- [Pricing](https://idlefy.com/pricing): full plan comparison and add-on pricing
- [MCP server for AI assistants](https://idlefy.com/mcp-server/): connect Claude Code, Claude, Cursor or Codex; what each role can do; the safety rules
- [Partner program](https://idlefy.com/partners/): 30% by default for four months on referred subscriptions, 30-day hold, $50 minimum payout, 60-day referral cookie, Wise or USDC — for cloud consultants and agencies
- [FAQ](https://idlefy.com/faq): security, setup, integrations, idle detection
- [How Idlefy works](https://idlefy.com/how-it-works): the lease lifecycle in detail — expiry warnings, the Pro Safety System grace, what survives a stop, and the IAM access boundary
- [Auto-shutdown for dev & staging environments](https://idlefy.com/solutions/dev-environments): why stopped-by-default beats schedulers for dev/test VMs, with workday-schedule list-price math per instance type
- [Auto-shutdown for GPU instances](https://idlefy.com/solutions/gpu): idle-hour list costs for GPU types, lease-based sharing of one expensive box, and the local scratch-disk caveat at stop
- [Instance cost reference](https://idlefy.com/cloud-costs): what each AWS and GCP instance type costs running 24/7 versus scheduled off outside work hours — 135 types priced at on-demand and spot list rates, per family, with per-type notes. Prices as of 2026-10-31.
- [Cloud GPU price comparison](https://idlefy.com/cloud-costs/gpu): on-demand and spot $/GPU-hour for NVIDIA B200 to T4 across AWS and Google Cloud, normalized per GPU, with idle monthly cost.
- [Cloud waste calculator](https://idlefy.com/tools/cloud-waste-calculator): estimate idle spend across a fleet from usage pattern, no signup
- [Schedule savings calculator](https://idlefy.com/tools/schedule-savings-calculator): pick an instance type and weekly hours, see the saving versus 24/7, no signup
- [Blog](https://idlefy.com/blog): case studies and engineering posts
- [RSS feed](https://idlefy.com/rss.xml): blog updates
- [Sitemap](https://idlefy.com/sitemap-index.xml): all indexable URLs
- [Idle Audit — what the free scan shows](https://idlefy.com/idle-audit/): the report's anatomy, the read-only boundaries, and the questions a security review asks, before you connect anything
- [Idle Audit](https://app.idlefy.com/idle-audit): free read-only 30-day waste scan of a connected AWS account or GCP project, no plan required
- [Sign up / app](https://app.idlefy.com): start a free account

## Optional

- [Terms of Service](https://idlefy.com/terms)
- [Privacy Policy](https://idlefy.com/privacy)
- [Legal notice](https://idlefy.com/legal)