Frequently asked questions

No. Latchkey works with GitHub organization accounts only; personal-account installs are rejected and automatically removed. Creating a GitHub organization is free and takes a minute.

No. Developer and Launch start a 30-day trial with no card. Scale goes through checkout with the trial applied.

The person who installs the GitHub App. There is exactly one owner per workspace, and ownership can be handed to another member later with Transfer Ownership. See Team and roles.

Yes. Each installation gets its own workspace with its own plan, team, repositories, and data, and the workspace switcher in the dashboard sidebar moves between them.

Yes. If you belong to several workspaces, the workspace switcher in the dashboard sidebar moves between them; each workspace has its own plan, team, and data.

No. You can skip repository selection and add repositories later from the dashboard's Monitoring modal. See Managing repositories.

Not yet: the dashboard is desktop-only, and mobile browsers see a blocking notice. Email, Slack, and push notifications cover you away from your desk.

Only the runs-on: line, and only for jobs you choose to move. Everything else stays as is, and GitHub-hosted runners keep working side by side.

Ubuntu 24.04 LTS on x86_64. There are no Windows, macOS, arm64, or GPU runners today; keep those jobs on other runners and mix freely within a workflow.

Yes, natively: Docker CE with BuildKit, buildx, and compose are preinstalled, including QEMU for multi-arch image builds.

Seconds when a warm runner is available (Launch and Scale include warm pool capacity); cold starts take about 10 seconds, vs 30-60 seconds typical for GitHub-hosted.

Up to 4 hours per runner; the machine is terminated at 4 hours even if the job is still running. Full limits in Limits and concurrency.

20 busy runners per workspace by default; idle warm runners do not count, and higher limits are available. Jobs beyond the ceiling wait for a slot.

No. Runners are single-use: one job per machine, destroyed afterward, so anything written to local disk is gone when the job ends. Use artifacts or caches for persistence.

In AWS us-east-1, on Ubuntu 24.04 LTS x86_64 machines. See Limits and concurrency.

Custom-configuration runners bill at the xlarge rate ($0.0200/min), whatever their shape. See Custom runners.

Yes: connect it to the Latchkey MCP server with an API key and it can triage failures, pull failure bundles, and drive fixes from your editor. See Connect your AI agent.

No. In-run fixes only touch the ephemeral runner, which is destroyed after the job. Durable fixes are only ever proposed as pull requests for your review, and nothing is auto-merged.

Yes: workspace-wide in Settings under Self-Healing (owners and admins), and per runner configuration on the Runners page. There is no per-repository toggle today.

No. It only intervenes on known transient classes (network, memory, disk, missing tools, config drift). Genuine code and test failures fail normally, and every heal is recorded in the Recent Heals feed.

Every intervention lands in the Recent Heals feed on the Runners page, with its category, verdict, and the action taken in plain language. Healed runs are also flagged in the Pipeline Performance runs table and deep-link to their heal report.

No. Retries are bounded per step, the AI diagnosis stage has a hard time budget of about three minutes, and the runner itself has a 4-hour lifetime cap. Details in Self-healing.

Workflow run and job metadata, and your workflow YAML files. Not your application source code, and never secrets or environment variable values. Details in Security and GitHub permissions.

Disabling a repository stops ingestion and archives its data. Canceling blocks access but retains your data so re-subscribing restores it. Deleting the workspace removes it permanently.

Per minute, rounded up per job, at per-size rates, after your plan's free minutes. See Runner usage and free minutes.

On the first of each calendar month. Minutes within the free tier cost nothing; only usage beyond it is billed at the per-minute rates.

With a subscription on file there is no hard cap: jobs keep running and the overage is metered to your invoice, with warnings at 80% and again at 100% of your included minutes. On a card-less trial, new managed-runner jobs are blocked once free minutes are exhausted, until you subscribe.

The subscription goes Past Due: dashboard and API access are blocked and runner launches stop until the payment method is fixed in the Stripe portal. Your data is unaffected. See Managing your subscription.

In the Stripe customer portal: open the Billing modal and click Manage Billing. Invoices (with PDFs), payment methods, and subscription details are all managed there.

Yes: Change Plan in the Billing modal upgrades or downgrades in place. Downgrading below your monitored-repository count asks you to choose which repositories stay monitored, and downgrading to Developer requires the workspace to have only one member. The trial does not restart on a plan change.

Launch includes 1 seat and Scale includes 5; extra seats are $5/month each. The Developer plan is for individual use, so team invites are unavailable there. See Team and roles.

No. Invites grant Admin or Member. To hand over the workspace, the owner uses Transfer Ownership.

You choose an expiry between 1 and 30 days (7 by default) and a maximum number of uses. Invites can be revoked any time from the Pending Invites tab.