Answers to everything
you're about to ask about Idlefy

One VM, up to five teammates, sessions capped at 24 hours, and web-only control (no Slack/Telegram bot). It's meant for personal sandboxes and kicking the tires — if you're running a real team on more than one server, you'll want Basic.

Basic ($50/mo) as soon as you want ChatOps (Slack/Telegram), RBAC, 48-hour sessions, or more than one VM.

Pro ($100/mo) when you want the Safety System, the AI-based idle detection, team audit logs, or 72-hour sessions. Most teams sit on Basic for a month and move to Pro once they've grown past five active VMs.

No. Monthly billing, cancel anytime from the dashboard. No annual lock-in, no "book a call to cancel" nonsense.

No. Keyless on both clouds: OIDC (Web Identity Federation) on AWS, Workload Identity Federation on GCP. Your cloud trusts Idlefy's identity provider and issues short-lived, automatically-rotated tokens. There are no access keys on our side to steal, lose, or rotate manually.

Everything scoped to what the product actually does. Auth is keyless on both clouds — OIDC (Web Identity Federation) on AWS, Workload Identity Federation on GCP. No IAM writes, no create/delete, no data-plane access, no touching disks or networking. Expand each provider below for the full list.

Nothing outside these lists. No DeleteInstances, no CreateInstances, no IAM writes, no disk or networking changes, no data-plane access. The full homepage IAM policy shows the AWS template verbatim — see it here.

TLS 1.2+ on every request. Operational metadata (VM IDs, tags, schedules, usage telemetry) is stored encrypted at rest in EU-region PostgreSQL. We do not touch or store any data from inside your instances — we only see what AWS/GCP APIs expose.

Yes — delete the IAM role in your cloud console and Idlefy is locked out immediately. No "contact support to disconnect" step. On AWS you can also take specific VMs outside the policy by removing the idlefy=enabled tag; on either cloud a VM can be disabled from the dashboard without revoking the whole connection.

Yes, on Basic and Pro plans. Each AWS account (or GCP project) gets its own OIDC role or Workload Identity binding, and all of them show up in the same Idlefy dashboard — one pane of glass across dev/stage/prod or AWS+GCP mixed estates.

Billing is per managed VM regardless of which cloud or account they sit in. No per-account charge.

Yes, on the Pro plan — it is part of the $100/mo list price, not an enterprise upsell behind a sales call.

Idlefy is an OpenID Connect relying party: authorization code flow with PKCE, with your provider's endpoints and signing keys read from its /.well-known/openid-configuration document. Okta and Auth0 are the two we test against live tenants; another provider works 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). Setup is issuer URL, client ID, client secret, done in the app under Organization. If your provider is set to sign with something else, tell us — widening that list is a small change on our side.

Your domain is proven, not just claimed. You add an email domain and publish a DNS TXT record for it; until that record resolves, the domain grants nothing. Matching is exact — verifying acme.com says nothing about eng.acme.com. We re-check daily, and a domain whose record disappears stops being trusted.

First-time users from a verified domain can have accounts created automatically — as members, on a team you pick, up to a cap you set. SSO never grants ownership. You can also require SSO, which removes password and Google sign-in for everyone on a verified domain. Organization owners are deliberately exempt — an unreachable identity provider must never lock you out of your own account.

Not supported: SAML, and SCIM directory sync. If either is a hard requirement, tell us at hello@idlefy.com — demand shapes what we build next.

Hosted in an EU datacenter certified to ISO/IEC 27001:2022. We store your account data and the VM metadata the AWS/GCP APIs expose (names, tags, usage data) — never the data inside your machines, and no workload data ever leaves your cloud.

DPA available on request at hello@idlefy.com.

It never stops a machine — it talks to you. Rented a VM and walked away? When it looks unused, idle detection sends a nudge — "Looks like you're not using this VM. Stop it to save?" — with one-tap stop and snooze buttons. That's how forgotten rentals die without taking anyone's work with them.

Pro adds an AI-based heuristic that recognizes real work patterns, so batch jobs and bursty workloads don't trigger false nudges. We deliberately don't publish the signals or thresholds behind it — what is guaranteed is the contract: shutdown happens only on the lease timer or your click.

One click. From Slack, Telegram, or the web dashboard: pick a duration (1h, 4h, or a custom length — up to 48h on Basic, 72h on Pro), hit the button. The VM boots back up — disk, IPs, everything intact — in about 60 seconds.

On-demand — recommended. This is the sweet spot for Idlefy. You only pay for the hours you actually use, and stopping VMs outside working hours typically drops total cost below a Spot 24/7 box — without any termination risk.

Spot — technically supported, not recommended. Spot instances can be terminated by the cloud provider at any moment. A cloud-initiated termination can look like one of our stop actions (or vice versa), which throws off Idlefy's state tracking and re-rent flow.

Your VMs keep their last state. Once Idlefy issued a stop, AWS/GCP did it — we don't hold anything in a "stopped" state server-side, so there's nothing to undo if we're unreachable. You can always start them directly from the AWS/GCP console. Short-lived OIDC/WIF tokens simply expire; no dangling access.

And because Idlefy is reachable from four independent channels — Slack, Telegram, macOS app, web UI — an outage on any one of them doesn't block the others.

Normal cloud disks (EBS on AWS, persistent disks on GCP): no — state survives stop/start cycles intact, that's how they're designed.

Instance store / local NVMe: yes — those are ephemeral by cloud-provider design, and their contents are lost on stop. This isn't Idlefy's behavior; it's how AWS and GCP built those instance types.

Recommendation: use EBS / persistent disks for any workload you can't afford to lose on a restart — then Idlefy's stop action is completely safe. You can also exclude specific instances from auto-stop via tags.

AWS and GCP in production today. Azure and Oracle Cloud are on the roadmap.

Install the app in your workspace (OAuth for Slack, bot link for Telegram), link it to your Idlefy team, and all idle warnings + one-click re-rent buttons land in the channel you pick. RBAC applies — only permitted roles see the control buttons.

Not yet — both are on the roadmap; Azure is marked "coming soon" on the providers grid. If one is blocking you from trying Idlefy, email hello@idlefy.com — customer demand shapes the release order.

No. Nothing to install — no daemon, no sidecar, no overhead inside your instances. Zero code changes required. Idlefy only uses what the AWS/GCP APIs already expose.

Absolutely — and we recommend it. Tag one non-critical VM with idlefy=enabled, watch the dashboard and Slack notifications for a few days, and roll out to the rest once you're comfortable. The Free plan exists precisely for this.

Yes. The platform is designed for fleets — our architecture handles thousands of VMs per organization, with RBAC and team-based views to keep things sane. Bulk-tagging tools, and auto-assignee once it lands on Basic and Pro, make onboarding a large estate straightforward.