Upstream eve
evestack is a distribution, not a fork — what eve documents, what evestack documents, and why the best eve docs are already on your disk.
evestack packages Vercel's eve. It does not fork it, wrap
its API, or re-document it. Every page here covers a seam that self-hosting creates — the
Postgres world, auth off-platform, the dashboard, the Docker sandbox — or a subject eve has no
page for at all. For the framework itself, these docs link out.
That is a deliberate policy, not a gap in coverage.
Why evestack does not mirror eve's docs
eve ships about two releases a day. Measured from npm on 2026-08-05
(npm view eve time --json): 37 releases in the 20 days ending 2026-08-04, or 1.85 per
day. Seven of them landed on 2026-08-04 alone — 0.30.0 through 0.30.6, from 14:26 to 23:01
UTC.
It is pre-1.0, so breaking changes ride minor versions. Seven minors shipped between
0.24.0 (2026-07-14) and 0.30.0 (2026-08-04). Two of them, from eve's own CHANGELOG.md:
| Version | Date | What broke |
|---|---|---|
0.29.0 | 2026-07-30 | eve trace renamed to eve traces; the singular form removed. eve channels add and the /channels and /connect TUI commands removed. |
0.30.0 | 2026-08-04 | localDev() grants on process state instead of the request host; the exported isLoopbackRequest helper removed; the default channel auth fallback changed to [vercelOidc(), localDev(), placeholderAuth()]. |
Those two landed five days apart. A mirrored copy of eve's docs would have been stale within a week and actively wrong about auth defaults and CLI commands within a month — which is worse than no copy, because a reader has no way to tell a stale page from a current one.
eve is Apache-2.0 and its docs ship inside the npm package under that same license, so evestack could legally mirror them. It chooses not to. The constraint here is accuracy, not permission.
Read the docs that match your pin
eve's package.json lists docs in its files array, so every install carries the full
documentation set for exactly the version you resolved. In a scaffolded evestack project:
ls node_modules/eve/docs
node -p "require('eve/package.json').version"Against the version this repo pins today — eve@0.30.8 — that is 82 Markdown pages in 12
subdirectories, 872 KB. These figures move with the pin; the two commands above are how you
re-measure them rather than trusting this paragraph. Some practical uses:
# every page mentioning the auth primitive you're debugging — 43 hits in 12 files
grep -rn "localDev" node_modules/eve/docs
# the guide for the version you actually run, not the version eve.dev documents
less node_modules/eve/docs/guides/auth-and-route-protection.md
# the changelog ships too — 1,008 lines of it at 0.30.8, and it grows every release
less node_modules/eve/CHANGELOG.mdThis beats the website for any pinned project, and eve says so itself. From
eve.dev/llms.txt: "prefer node_modules/eve/docs/: those docs
match the installed eve version".
eve.dev always documents the latest release. On a day like 2026-08-04 that is up to seven versions ahead of what you installed this morning. When a website page and your local copy disagree, your local copy is the one describing the code you are running.
The site does serve Markdown directly — append .md to any docs URL, and
eve.dev/sitemap.md lists every page — which is the right source
when you are deliberately reading ahead of your pin, for example while reviewing an
upgrade.
Who documents what
eve owns the framework
Everything about authoring and running an agent is upstream. These links point at eve.dev
because they describe eve's surface, not evestack's; read the matching file under
node_modules/eve/docs/ when the version matters.
| Topic | Upstream page |
|---|---|
| Agent configuration — model, reasoning effort, compaction | agent-config |
| Tools | tools |
| Approvals and human-in-the-loop gating | human-in-the-loop |
| Subagents | subagents |
| Skills | skills |
| Channels — HTTP, Slack, Discord, GitHub, Linear | channels/overview |
| Connections — MCP and OpenAPI servers | connections |
| Extensions | extensions |
| Sandbox — shell, filesystem, lifecycle, network policy | sandbox |
| Schedules | schedules |
| Evals | evals/overview |
| CLI reference | reference/cli |
| TypeScript API | reference/typescript-api |
| Execution model and durability | concepts/execution-model-and-durability |
| Security model | concepts/security-model |
| Auth and route protection | guides/auth-and-route-protection |
| Instrumentation and OpenTelemetry export | guides/instrumentation |
| Deploying to Vercel, and framework-level self-hosting | guides/deployment/self-hosting |
evestack owns the seam
| Topic | Page |
|---|---|
| The dashboard — sessions, turns, tokens, computed cost, driving the agent | /docs/dashboard |
| Running the whole stack on your own hardware | /docs/self-hosting |
Postgres as the workflow world, and the @beta pinning trap | /docs/local-setup |
| Long-term memory on pgvector | /docs/memory |
The @evestack registry, and taking one piece into an existing eve project | /docs/registry |
| Keeping up with a framework that ships daily | /docs/upgrading |
| Failures specific to running off-platform | /docs/troubleshooting |
The dividing rule: a page belongs here when self-hosting changes the answer. eve's self-hosting guide tells you the framework supports running off Vercel; /docs/self-hosting is the runbook for the machine you actually have. eve's instrumentation guide tells you how to export spans; Architecture explains why evestack's dashboard reads Postgres instead.
Memory: eve ships no first-party store, on purpose
https://eve.dev/docs/memory returns 404, and no file under node_modules/eve/docs/ has
"memory" in its name except patterns/multi-tenant-memory.md. That page is a composition
pattern — route auth, dynamic instructions, and ordinary tools — and it states plainly that the
storage implementation sits outside eve, naming PostgreSQL, a durable KV store, or a vector
database as equally valid.
An earlier version of this page, and the comparison table on Introduction, reached "not included" from that — by quoting the page's second paragraph and cutting its first. Restored in full, the page opens:
You can add long-term memory from the integration gallery using the Memory filter, or build tenant-aware memory from your own application store by composing three existing eve primitives.
So memory is available upstream, via the gallery. Reading only the sentence that suited us is exactly the failure mode these docs exist to avoid, and it is corrected here.
The accurate claim is narrower and still worth making. eve ships no first-party memory store — "The storage implementation is deliberately outside eve" — and the gallery's packaged options are third-party hosted services: Mem0 ("persistent memory for AI agents and assistants") and Upstash AgentKit ("long-term memory, Redis Search, and durable chat history"). Both are somebody else's SaaS holding your agent's recollections.
That is the part a self-hosted operator has to decide, and there is nothing upstream to link
for it. /docs/memory fills it: remember and recall on the Postgres already
running your sessions, indexed with HNSW rather than IVFFlat, with the measured reason that
choice is a correctness fix and not a preference. Same data ownership as the rest of the
stack — no third party, no extra container.
Attribution
evestack is built on vercel/eve and is licensed Apache-2.0, same as eve. eve is a trademark of Vercel; evestack is an independent project and is not affiliated with or endorsed by Vercel.
It is also not the first self-hosted eve distribution. vercel-labs/steve — "Self-hosted eve poc" — was published on 2026-06-24 by a Vercel employee, weeks before this project started. Any claim that self-hosting is a thing Vercel withheld is refuted by their own repo.