Upgrade from 0.x or a release candidate
You will be on 2.0, coming from a 1.5.0 release candidate, an install from before
the kraft-sdlc rename, or a Kraft 0.x home. A 1.4 install follows
Upgrade from 1.4, and an upgrade between 2.x
releases needs only Upgrade Kraft.
- On a 1.5.0 release candidate: go to Upgrading from a 1.5.0 release candidate.
- On a 0.x install, or one from before the
kraft-sdlcrename: go to Upgrading from older releases.
Before you start
- You know which release you run:
kraft --versionprints it. - You know how Kraft was installed: with uv or
install.sh, with Homebrew, or with pipx. The install command differs for each. - You can pick a moment when no agent runs, or you will pause the running items first. See A restart ends running agents.
Upgrading from a 1.5.0 release candidate
The 1.5.0 release candidates, 1.5.0rc1 to 1.5.0rc14, were the pre-releases of
2.0. No 1.5.0 was released.
- Back up the database, as step 1 of Upgrade says. Keep the file name it prints: a rollback to 1.4 needs it.
- Update or install, by the candidate you run. Pause the running items first, or
wait until none run. Which command updates you depends on the candidate:
- 1.5.0rc14:
kraft admin updatefollows the release-candidate channel, so it moves to 2.0's candidates, and to 2.0.0 once that is out, and keeps[vector]and your Python.kraft admin update --channel stablewaits for 2.0.0. - 1.5.0rc13:
kraft admin updatefollows the release-candidate channel too, but installs without[vector]and on uv's default Python, as 1.4's does. Use theuv tool installcommand from Update from 1.4 instead, naming the release you want (such as2.0.0). Then runkraft admin restart. - An earlier candidate:
kraft admin updatecompares against stable releases and says you are up to date. Use the sameuv tool installcommand. Itskraft admin update --channel rcinstalls the candidate too, but drops[vector]and the Python as rc13's does.
- 1.5.0rc14:
- Restart the server with
kraft admin restart, unless step 2 already did. It lists the running items and asks before it ends their agents. - Check the result with
kraft --versionandkraft admin health. Both print the release you installed, as step 5 of Upgrade shows.
After an update run by rc14 or earlier, vector search may have stopped. Reinstall the extra as in Enable vector search.
An update run by rc14 keeps the extra, but where uv had recorded no Python for
Kraft (an install without --python, install.sh, or one that 1.4 or an earlier
candidate updated), it records the exact interpreter it ran on, one Python patch
release (…/cpython-3.13.12-…/bin/python3.13). Every later kraft admin update
keeps it, so uv python upgrade leaves Kraft behind, and removing that patch
release breaks kraft.
To fix that, run grep python "$(uv tool dir)/kraft-sdlc/uv-receipt.toml" to see
what uv recorded. If it is a path, run the uv tool install --force --python 3.X …
command once to tie Kraft to the minor version.
The VS Code extension on the Marketplace stays at 1.4 until 2.0.0 ships, and is
read-only against a 2.0 release candidate. Install the kraft-<version>.vsix
attached to the candidate's GitHub release with
code --install-extension kraft-<version>.vsix.
What a candidate already did stays done:
- 2.0 migrates the database from the schema the candidate left. It copies the database first as any upgrade does, unless the candidate already ran 2.0's schema 52 (2.0.0rc9 and later), when it makes none.
- A theme the candidate converted keeps its
theme.yaml.pre-1.5(theme.yaml.pre-ux2from rc5 to rc9). - A
uv.lockthat an open item's setup command wrote under 1.5.0rc14 was recorded without a digest. When the item rebases, Kraft sets aside a lockfile the setup wrote and nobody changed, but keeps one with no digest in place, in case the agent edited it. The rebase can then stop on it: see Git would not start the rebase. No action; items started on 2.0 are recorded with a digest.
To roll back to 1.4 from there, you need the database as 1.4 left it, schema 44: your own backup, or the copy Kraft made when you first left 1.4, which is not the newest one. See Find the copy to restore. Which copy holds it depends on the first release you ran after 1.4:
- 1.5.0rc1 to rc11: no copy. These made none, so only your own backup rolls back.
- 1.5.0rc12 or rc13:
pre-v50-*. - 1.5.0rc14, or 2.0.0rc1 to rc8:
pre-v51-*. - 2.0.0rc9 or later, 2.0 included:
pre-v52-*.
Any later upgrade adds a newer copy that holds the schema before it, which 1.4 refuses.
Upgrading from older releases
An install from before the kraft-sdlc rename
An older install can still hold a kraft uv tool next to kraft-sdlc.
kraft admin update then stops and names the two commands that clear it:
uv tool uninstall kraft
uv tool install --force --reinstall kraft-sdlc
The reinstall is needed because the uninstall removes the kraft command both
packages share.
Migrating a home from 0.x
A Kraft home from 0.x holds a registry.yaml and no library.yaml. Kraft does
not convert or overwrite it: the server starts degraded and refuses new work
until kraft admin update replaces the configuration. Since 1.0, a template
configuration is a library.yaml plus chains/*.yaml.
- Get ready.
- Read the 1.0.0 changelog. Harness profile names and the template layout changed.
- Finish or abandon in-flight items.
- Stop the old server with
kraft admin stop. It printskraft: stopped (pid N), orkraft: no server runningwhen none runs. The command exists from 0.6.0. On an older install, stop the server in the terminal it runs in, or end its process from your process list. - Back up the database, as step 1 of Upgrade says. The update keeps the old configuration whole in a backup folder of its own, so that needs no copy of yours.
- Install 2.0 with the tool you installed Kraft with, as
Install shows.
kraft --versionprintskraftand a 2.x release. - Run the update:
kraft admin update
It works on the directory that holds the 0.x files, whether or not a server has started since you installed. It says what will change, then asks:kraft: /home/you/.kraft/config holds a Kraft 0.x template configuration (a hook registry and gate_after chains). It is not compatible with this Kraft, which runs only the library.yaml format 1.0 introduced, and there is no migration: replacing it installs the bundled configuration and moves the old one, whole, to a backup at /home/you/.kraft/config.pre-v1-20261002-093015 Carried across unchanged: access.yaml, notify.yaml, theme.yaml, repos.yaml, intake.yaml, harnesses. policy.yaml keeps your value for every key the current format still has; any other key is dropped and listed. Your chains and registry.yaml are replaced. All of it stays in the backup. Replace it? [y/N]
The backup folder sits beside the directory it replaces and takes its name:config.pre-v1-<time>, ortemplates.pre-v1-<time>when no 2.0 server has started yet. Answery. With-ythe command asks nothing. With no terminal and no-y, it printskraft admin update: nothing changed. Answer y, or pass -y, to replace it.and exits 1.
After you accept, it prints what it did:kraft: installed the bundled configuration in /home/you/.kraft/config; the old one is at /home/you/.kraft/config.pre-v1-20261002-093015 kraft: policy.yaml: dropped <key> = <old value> (the current format has no such key, or refuses the value)
Thedroppedline appears once for each key the update drops. When the 0.xpolicy.yamlcannot be read, it printskraft: policy.yaml: no readable 0.x policy; the default is installedinstead.
The update then goes on to check for a newer release. When there is none, it printskraft 2.0.0 is up to date (v2.0.0 is the newest release)and ends, with no restart line. When a newer release exists, it installs it and printsRestart a running server: kraft admin restart; step 4 covers the restart either way.
When the release feed is unreachable, the command exits 1 after the configuration was replaced. Running it again changes no configuration, because no 0.x files are left. - Start the server, or restart the one that is running. A server that came up
before the update still holds its degraded state, and the update does not tell it
to reload.
- No server is running: run
kraft admin start --detach. - A server is running: run
kraft admin restart, which ends the agent of every active item. See A restart ends running agents.kraft admin reloadloads the new library, chains,policy.yamlandintake.yamlwith no restart, and leaves every other file as the server read it when it started.
- No server is running: run
- Check the result, as Check it worked says.
What the update does to your files:
access.yaml,notify.yaml,theme.yaml,repos.yaml,intake.yamlandharnesses/carry across.- A
steering/directory does not carry across: it stays in theconfig.pre-v1-<time>backup, and nothing folds it intolibrary.yamlany more, so copy its text intolibrary.yaml'ssteering:by hand. policy.yamlstarts from the shipped default and keeps your value for every key the current format still has. Kraft prints each key it drops, with its old value.- Your old chains and registry stay only in the backup. There is no migration helper.
An update interrupted mid-swap is finished by the next start or the next
kraft admin update, which prints
kraft: finished an interrupted update: installed the staged template configuration in <the directory>; the old one is at <the backup>.
Check it worked
kraft --version
kraft admin health
status ok
version 2.0.0
You know it worked when --version prints a 2.x release and the status row of
health says ok. A server that still refuses work reads degraded and adds an
invalid template row that names the reason. If it names the 0.x configuration,
the server has not read the new one yet: do step 4 of
Migrating a home from 0.x.
Next steps
- Upgrade from 1.4: what 2.0 changes from 1.4, which this page leaves out
- Upgrade Kraft: the backup, the update and the check that every upgrade uses
- Back up and restore the database: find the copy to roll back to
- Roll back to 1.4: go back if the upgrade went wrong