Support

This page is deliberately unambitious. Everything on it is a statement about what CI runs and what the manifests declare, so you can check it yourself rather than take it on trust. Where something is untested, it says so.

Which versions get fixes

The newest published version of the affected package. Nothing else.

Fixes land on main and go out in that package's next release. There is no long-term-support line, no maintenance branch per version, and nothing is backported. If you are two versions behind and hit a bug, the answer will be "upgrade" — see Upgrading.

Three things ship on separate clocks, which matters when you read "fixed in":

That third row is the one that surprises people. create-evestack copies the template into your directory and then has no further relationship with it. There is no evestack upgrade command — packages/evestack-cli/src/ has no such module — so Upgrading describes the diff-and-apply routine that stands in for one.

What the version numbers promise

Every published package is 0.x. Under npm's own rules a caret range on a 0.x version only admits patch releases — ^0.2.0 will take 0.2.1 and will not take 0.3.0 — and that is the promise being relied on here rather than worked around.

• A minor bump (0.2.x → 0.3.0) may break you. Pre-1.0, that is what the minor position is for.
• A patch bump is fixes only.
• No package has reached 1.0, so nothing here is claiming API stability yet.

evestack, create-evestack and @evestack/mcp declare no eve peer range, because they do not import eve. The scaffolder ships the template; the CLI and the MCP server talk to a dashboard over HTTP.

Platforms

Node

Node 24, and the current major alongside it. All seven published packages declare "engines": { "node": ">=24" }, as do the repository root and the template a scaffold gets. CI installs 24 everywhere and 26 as well on the two jobs cheap enough to matrix: typecheck and registry in .github/workflows/ci.yml run node-version: [24, 26] with fail-fast: false, and the remaining five actions/setup-node steps pin 24. So 24 is the floor and 26 is checked; anything between them is inferred, not tested.

The floor is enforced rather than merely advertised: nodeVersionProblem() in packages/create-evestack/shared.mjs refuses an older runtime with a message naming the version, because engines is advice that npm prints and installs through anyway. The generated project's scripts use --env-file-if-exists (Node 20.12+) and its checks call URL.parse (Node 22.1+), so an older Node fails several commands later in a message that never names the real cause.

Operating systems

macOS

A macos-latest job runs on every PR. It is marked continue-on-error: true, so it reports without being able to block a merge — the table above says partly tested, and that is the honest word for it.

What it runs. pnpm -r typecheck; the static contract tier (node contract/run.mjs — 545 assertions, under two seconds on darwin); create-evestack's suite, whose file-mode assertions gate on process.platform !== "win32" and check that generated credential files land at 0600, which is the likeliest place for an APFS-versus-ext4 difference to surface on a security-relevant path; and the template's own suite, which resolves node_modules/.bin/eve under a scrubbed PATH and spawns without a shell.

What it deliberately leaves out. Anything that needs a Docker daemon. Five jobs across this repo's workflows — runtime in ci.yml, plus provider-bisect.yml, evals.yml, eve-watch.yml and dashboard-image.yml — declare a services: block, and GitHub-hosted macOS runners have no daemon to back one. Porting them would mean dropping the contract runner's --require flag, which downgrades a probe that cannot run from a failure to a skip: green having checked nothing. Playwright is out for the same class of reason — the install step uses --with-deps, which is an apt-get path.

What is still uncovered. There are four darwin branches in the tree, not three: the open-a-browser helpers at packages/evestack-cli/src/project.mjs:354, packages/evestack-cli/src/tour.mjs:393 and templates/default/scripts/verify.mjs:569, plus contract/runtime/repro/eve-turn-wedge.mjs:162, which shells out to sysctl -n vm.swapusage. The macOS job executes none of them — it launches no browser, and the fourth lives in the runtime tier that does not run there. The job narrows the macOS gap; it does not close it.

Windows

This is stated bluntly because the code looks like it supports Windows. The twelve branches, so you can judge the risk yourself:

• Opening a browser — packages/evestack-cli/src/project.mjs:357, packages/evestack-cli/src/tour.mjs:396, templates/default/scripts/verify.mjs:651 each pick cmd /c start over open / xdg-open. Find them with rg -n "cmd\", \[\"/c\", \"start\"" packages templates rather than by line number.
• Spawning npm and docker — packages/create-evestack/create.mjs:231, :354 and :1185, templates/default/scripts/dev.mjs:81, templates/default/scripts/start.mjs:60, templates/default/scripts/eval.mjs:148 pass shell: process.platform === "win32", which is how a .cmd shim gets found on Windows. Find them with rg -n 'shell: process.platform' packages templates.
• Naming the eve binary — templates/default/scripts/checks.mjs:532 returns eve rather than eve.cmd. This is the one with a test: templates/default/test/eve-binary.test.mjs:115 calls eveBinary(url, "win32") on Linux, which checks the string and nothing about Windows.
• Terminal glyphs — packages/create-evestack/ui.mjs:68 and templates/default/scripts/ui.mjs:68 fall back to ASCII outside Windows Terminal. That file's own comment is the honest summary: the failure mode is "mojibake in a legacy Windows code page — one nobody here can reproduce."

packages/create-evestack/test/attach-writes.test.mjs gates its file-permission assertions on process.platform !== "win32", so even if you ran the suite on Windows, the checks on credential file modes would skip rather than fail.

If Windows matters to you, a CI job on windows-latest is the contribution that would change this row — not a bug report saying it did not work.

There is a cheaper contribution than that, though, and eveBinary is the worked example of it. Its signature is eveBinary(scriptUrl, platform = process.platform): the default keeps every caller unchanged, and passing "win32" explicitly makes the Windows branch reachable from a test on the runner this repo already pays for. That is why one of the twelve is covered and eleven are not — not because the others are harder, but because they read process.platform directly instead of taking it as an argument. Threading the same defaulted parameter through the other eleven would convert them into tested branches on Linux, and would leave a windows-latest job as a nice-to-have rather than the only way to move this row.

Everything else

• Docker. Both compose files run Postgres in it, and the scaffolded sandbox is eve/sandbox/docker (templates/default/agent/sandbox/sandbox.ts), so every tested path has it. Pointing the agent at a Postgres you host elsewhere is not tested here.
• Postgres is tested as pgvector/pgvector:pg17 — the image both compose files run, and the one CI's services: block starts. The vector extension is not optional if you use memory: templates/default/lib/memory.ts runs CREATE EXTENSION IF NOT EXISTS vector and stores a vector(n) column.
• Browsers. The dashboard is a Next app and has no browser test matrix. The only browser CI ever launches is Chromium, and that is for the marketing site's Playwright suite, not the dashboard.
• eve is pinned at ^0.30.8 in templates/default/package.json. Below 0.30.0 is a security floor, not a preference.

What "supported" means here

evestack is a small open-source project with a contract suite, not a vendor with an SLA. What you can rely on:

1. Reported bugs get read. Open an issue at github.com/SammyTourani/evestack.
2. Security reports get a reply within 72 hours, and a fix or mitigation before public disclosure. See SECURITY.md.
3. Assumptions about eve are checked by machine, not by memory. contract/ is 22 contracts that go red when eve's behaviour drifts under them, and eve-watch runs them against every new eve release daily. That is the closest thing here to a compatibility guarantee, and it is stronger than a promise because it is executable.

What you should not rely on: a response time on a feature request, a deprecation window, or a version staying installable forever.