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 network. Expand each provider below for the full list.

Nothing outside these lists. No DeleteInstances, no CreateInstances, no IAM writes, no disk or network mutation, 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. You can also disable specific VMs by removing the idlefy=enabled tag 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 only your account email — no workload data ever leaves your cloud. Everything we see about your VMs is what the AWS/GCP APIs expose (names, tags, telemetry) — never the data inside them.

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, Smart Pulse 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. The exact signals and thresholds are our secret sauce — what's 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, custom up to 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 behaviour; 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 in active development (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 and 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 (Pro) make onboarding a large estate painless.