# November Update: Latchkey CI Is Live > October shipped Latchkey CI: commit a workflow file and Latchkey runs it and reports back as checks. Plus a guided move from GitHub Actions, secrets, spend limits and CLI 0.9. Source: https://latchkey.dev/blog/latchkey-ci-is-live Kaveh Alemi Published 2026-11-01 **TL;DR** Latchkey CI is live: commit a workflow file under `.latchkey/workflows/` and Latchkey runs it on fresh machines and reports back as checks. Migrate moves a repository from GitHub Actions in one pull request and lets you compare both side by side first. Next, we make the first run easier and let agents propose pipeline changes you approve. ## Shipped in October - **Latchkey CI.** Commit a workflow file under `.latchkey/workflows/` and every push runs it on fresh Latchkey runners, with results as checks on your pull request. - **Migrate from GitHub Actions.** Latchkey reads your GitHub Actions workflows, opens one pull request with their Latchkey versions, and runs both side by side until you switch. - **Secrets and environments.** Secrets live in Latchkey and reach only the step that names them, and deploy jobs can wait for an approval and get a short-lived identity token for your cloud. - **Spend limits and batch budgets.** Cap what your runners may cost in a month, and give an agent's batch of jobs a dollar budget it cannot raise. - **Latchkey CLI 0.9.** `latchkey cache`, `latchkey wait`, `latchkey artifact`, `latchkey validate` and `latchkey migrate` join `latchkey run`. - **A dashboard built around runs.** A rebuilt dashboard with a Runs page, a run page that draws every job and its live log, and an Easy or Pro level of detail. - **Plan and billing changes.** Free minutes now count by runner size, runner minutes past them arrive on their own invoice, and Launch includes three seats. Last issue ended with a promise: running whole pipelines on Latchkey, not just single commands. In October it reached production, and most of what else shipped this month exists to make it practical to move onto. ![Latchkey Ledger No. 11: Latchkey CI is live, October 2026](/blog/images/ledger-2026-11-cover.png) ## Latchkey CI Until October, Latchkey ran your jobs in one of two ways: GitHub Actions jobs on our managed runners, or one-off commands from the CLI. Latchkey CI is the third and the biggest: Latchkey runs the pipeline itself. ![A workflow file under .latchkey/workflows/ and the checks a push writes back to the pull request](/blog/images/ledger-2026-11-workflow.png) **How you use it.** Commit a workflow file under `.latchkey/workflows/`, one file per pipeline, in the shape you already know from GitHub Actions: `on:` for the pushes and pull requests that start it, jobs with `runs-on:` naming a Latchkey size (`small`, `medium`, `large` or `xlarge`), and steps with `run:`. Push, and Latchkey runs the file as it stands at that commit, on fresh machines, and writes the result back to your pull request as checks, for the run and for each of its jobs. A file can already carry most of what a real pipeline needs: `needs:` to order jobs, a matrix, service containers, job `outputs:`, `if:` conditions, `concurrency:` groups that keep the newest waiting run, and `on: workflow_dispatch` to start a run by hand from the Runs page or through your agent. Jobs pass files to each other with artifacts and keep dependencies between runs with the cache steps. **Why it works that way.** Latchkey does not run GitHub actions, and we will not emulate them. A `uses:` line names one of our own versioned steps (`latchkey/cache-restore`, `latchkey/setup-node`, `latchkey/aws-login` and a few more), and checkout is automatic. The runner image carries twelve language toolchains, so most `actions/setup-*` steps simply go away. When a file asks for something we do not support, Latchkey refuses it by name, with the line, instead of running it with a key quietly ignored. That is the "reasons, not silence" item from last issue's list: a run that does not happen tells you why. **What it deliberately does not do yet.** We recommend you do not mark Latchkey checks as required in branch protection yet. A check Latchkey cannot write stays absent, and a required absent check blocks the merge. GitHub Actions keeps working exactly as before, and a personal GitHub account can run Latchkey CI, with no organization needed. ## Migrate from GitHub Actions Nobody rewrites a working pipeline on faith, so the way onto Latchkey CI is a guided move you can check before you commit to it. Open **Migrate** in the dashboard and pick a repository. Five steps follow. ![The five Migrate steps: Connect, Plan, Secrets, Apply, Side by side, then Switch to Latchkey CI](/blog/images/ledger-2026-11-migrate.png) **Connect** reads the repository's GitHub Actions workflow files. **Plan** shows, for each pipeline, the Latchkey workflow file it becomes: what moves as written, what becomes a Latchkey step, and each item that needs a person's answer, such as a third-party action with no direct equivalent. **Secrets** lists the secret names your workflows read and carries their values to Latchkey, either typed in yourself or carried straight from GitHub by a short-lived workflow that you approve by merging its pull request and that is removed again afterwards. **Apply** opens one pull request that adds the Latchkey workflow files. Then comes the part that makes it safe. After the apply, the repository runs in advisory mode: both CIs run on every commit, and a Latchkey failure is written as a neutral check whose title says what really happened, such as "Advisory: failed", so nothing blocks a merge. **Side by side** compares the two results commit by commit. A deploy job can run as a dry run while you trial it, so a trial never ships twice. When you trust what you see, **Switch to Latchkey CI** opens the pull request that removes the GitHub Actions files Latchkey replaces. If another workflow on GitHub Actions only ran after one of them, the switch pull request names it first, so nothing goes quiet without warning. The same flow is in the CLI as `latchkey migrate plan`, `apply` and `status`, and through MCP for your coding agent. ## Secrets and environments A pipeline that deploys needs credentials, and the right place for them is somewhere only the step that uses them can see. **Secrets.** Set a secret for the workspace, a repository or an environment, on the Secrets tab in Settings or with `latchkey secrets set`. A step reads one as `${{ secrets.NAME }}` in its `env:`, and Latchkey hands the value to that step alone, not to the job's other steps. The Secrets tab shows each secret's versions and which pipelines read it. A run of a pull request from a fork gets no secrets at all. **Environments.** A job can name an `environment:`, and an environment can accept jobs only from the branches you set and wait for an owner or admin to approve the run before the job starts. **Cloud identity.** Instead of storing long-lived cloud keys, a job can ask for a short-lived identity token that your cloud account trusts. `latchkey/aws-login` does it for AWS in one step, `latchkey oidc request-token` does it for anything else, and the docs walk through setting up the trust on AWS, Google Cloud and Microsoft Entra. ## Spend limits and batch budgets Agents run CI in bursts, and a burst should have a ceiling you chose. On the Billing page, an owner or admin can now set a **spend limit**: the most the workspace's runners may cost this calendar month. At the limit, Latchkey refuses new jobs, holds queued ones and stops running ones. Inside that, jobs can be grouped into **batches** with a dollar **budget** each. `latchkey run --batch ` puts a job in a batch, `latchkey budget set` caps it, and `latchkey run --budget ` caps a single job. An API key can set a batch's first budget or lower it, but only an owner or admin can raise one, so an agent cannot talk itself into more money. The Billing page lists every batch with its budget and what its jobs have cost so far. ## Latchkey CLI 0.9 The CLI went from 0.3 to 0.9 in October. The highlights: - `latchkey cache restore` and `save` keep dependency downloads from one run to the next, the cache last issue said was coming. - `latchkey wait` waits for a set of jobs or a whole batch and exits 0 only if every one passed. - `latchkey artifact upload` and `download` pass files between the jobs of a run. - `latchkey validate ` checks a workflow file the way Latchkey compiles it, and prints the most one run can cost at list rates. Every refusal now carries a code, `latchkey run` packs exactly what a fresh clone would contain, and the CLI tells you when a newer version is out. The [changelog](/documentation/latchkey-cli) lists every release. ## A dashboard built around runs The dashboard was rebuilt around five places: Home, Runs, Runners, Insight and Settings. **Runs** lists what is running now and everything before it, with the cost of each job and a Cancel button. A **run page** draws the run's jobs as a board in the order their `needs:` give, with matrix legs, service containers and self-heal on each tile. A job's log streams live step by step, with search, a raw view and line numbers. Everyone can pick a level of detail: **Easy** keeps each page to what most people check, **Pro** shows every number. A command palette jumps anywhere, and a failed job offers **Hand to agent**, a prompt your coding agent can pick up from there. ## Plan and billing changes Three changes to how plans work, all visible on the Billing page and in the [docs](/documentation/runner-usage-and-free-minutes). **Free minutes count by runner size.** Every plan's allowance is unchanged (2,000 a month on Developer, 4,000 on Launch, 6,000 on Scale), but it is now counted in small-equivalent minutes: a minute on `small` counts as one, `medium` as two, `large` as four and `xlarge` as eight. The allowance resets on the first of each calendar month. **Runner minutes get their own invoice.** Minutes past your allowance are billed on a separate invoice on the 1st of each month for the month just ended, apart from your plan's invoice. Rates are unchanged, from $0.0025 a minute on `small`. **Launch includes three seats**, up from one, with extra seats at $5 a month. ## Coming next The direction for the coming months is getting teams that already use GitHub Actions onto Latchkey CI and keeping them there. Three things are in motion: - **An easier first run.** Fewer steps between signing up and a green run, whether you start from a repository or from the terminal. - **Agents that change pipelines the way people do.** An agent will propose a pipeline change as a pull request, Latchkey will show what the change does to the pipeline before you merge, and the merge is the approval. - **Speed and reliability.** Latchkey CI jobs will get priority over batches of agent jobs when your workspace is busy, and self-heal will say on the check itself when it kept a job green. GitHub Actions on Latchkey runners stays a supported way to run CI. If you move a repository with Migrate and something in the plan needs an answer we do not have yet, tell us through the [Support page](/support). Previous issue: [October Update: Refer & Earn, and Billing You Can See Coming](/blog/refer-and-earn-and-billing-you-can-see-coming) --- Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt