The personal agent template that calls itself self hosted but needs Vercel's database and Blob

Self hosting still means provisioning Neon and a Blob store

The self hosting path is five commands and looks local:

git clone https://github.com/vercel-labs/personal-agent-template.git
cd personal-agent-template

pnpm install
cp .env.example .env
pnpm db:migrate
pnpm dev

What the surrounding configuration needs is not local. The database comment in `.env.example` says the database is required everywhere, including local development, that NuxtHub is pinned to PostgreSQL so there is no local file fallback, and that it is provisioned through the Neon integration on the Vercel Marketplace with `vercel integration add neon` followed by `vercel env pull`. Memory is worse in the same way: documents live in private Vercel Blob storage, and the same file says a Blob store has to be attached to the project, with `BLOB_READ_WRITE_TOKEN` set automatically once it is. So a developer with no Vercel account reaches the point of running migrations and cannot.

Both shared secrets ship as the same placeholder string

Two secrets gate the system and `.env.example` fills both with the identical value, `change-me-to-a-random-string-at-least-32-chars`, one for `BETTER_AUTH_SECRET` and one for `INTERNAL_API_SECRET`. The comments tell you to generate each with `openssl rand -base64 32`, which produces a 44 character string rather than the 32 the placeholder names, and the second one is documented as the shared secret between the Eve agent and the Nuxt internal API, with the note that it must match on both the Nuxt app and the Eve service in production. The deploy link carries the same three variables, `BETTER_AUTH_SECRET`, `BETTER_AUTH_URL` and `INTERNAL_API_SECRET`, described as a shared secret for web and Eve. A fork that copies the example file and fills in only one of the two gets a working local app and a production split where the two services disagree about the Bearer token.

The architecture diagram opens its last box and stops

The diagram in the architecture section draws web chat and Slack DMs at the top, an Eve agent box for channels, tools and skills below it, an arrow labelled `/api/internal/* (Bearer auth)`, and then a third box that consists of a top border and nothing else. The layer the authenticated arrow points into is the one with no contents, which is where the memory routes and the Slack and phone link reads described in the how it works list live. The prose picks up the slack instead: on Vercel the deployment splits into two services, `web` running Nuxt and `eve` running the agent runtime, and the `eve/nuxt` module generates that second service and its `/eve/v1/*` route during the build, with nothing to declare in `vercel.json`. So the diagram understates one hop and one generated service rather than mislabelling them. The same split is why the transcript can be thin: Eve holds it, so the web side stores a session id and nothing else, and threads resume across sessions and across tool calls with those calls rendered as they arrive.

npx auth@latest is the one tool the lock file cannot pin

Everything in this repository is pinned: `packageManager` is `[email protected]`, `engines` demands Node 24 or newer, and a `pnpm-lock.yaml` and `pnpm-workspace.yaml` sit at the root. The schema generator is the exception. `auth:schema` runs `npx auth@latest generate --config server/utils/auth.ts --output server/db/schema/auth.ts -y` and then lints the file it just wrote with `eslint --fix`, `db:generate` chains that into `nuxt db generate`, and `db:migrate` is `nuxt db migrate`. A file named `auth.ts` also sits at the repository root while the generator is pointed at `server/utils/auth.ts`, so the path that decides the schema is not the path at the top level. Fetching a CLI by `latest` at generation time means the migration you produce depends on which version of that tool your machine resolved that day.

The description promises approved memory saves, the memory tools have no approval step

The one line description advertises long-term memory with user-approved saves, and the memory section describes something else. The `profile` slot, bound in `agent/memory/profile.ts` to Eve's `fileMemory()` provider, holds a bounded, model-maintained list of durable facts scoped per authenticated principal, recalled before every turn and after compaction, and the agent is handed `profile__save_memory` and `profile__remove_memory` to maintain it as the conversation warrants. Nothing in that description inserts a confirmation step between the agent and its own memory. The approval machinery in this template is documented somewhere else: the GitHub tools, mounted from `@github-tools/eve-extension` through Vercel Connect, come with durable approval on writes. So writes to your repositories are gated and writes to your own memory profile are not, and the description does not make that distinction. The daily summary skill sits on the same footing, assembling an active focus from recalled memory plus assigned Linear issues and one suggested next action, triggered from a home quick action or asked for in chat, so what it reports about your day is drawn from the entries the agent chose to keep.

One package, two tsconfigs, and a second service generated at build time

The agent is not a separate package. `imports` in package.json maps `#*` to `./agent/*`, so agent code is reached through a subpath import of the same package, the root carries `agent/` next to `app/`, `server/` and `shared/`, and there is one `package.json` with one dependency list. Type checking is split instead: `tsconfig.json` and `tsconfig.agent.json` at the root, `pnpm typecheck` running `nuxt typecheck && tsc -p tsconfig.agent.json`, and separate `typecheck:app` and `typecheck:agent` scripts, with `build:agent` calling `eve build` alongside the ordinary `nuxt build`. `nuxt prepare` runs twice, once in `postinstall` and once at the head of `dev`. The practical consequence is that the app and the agent share a dependency tree and a lock file, so a version bump in one moves both.

Persona V is a placeholder, and the guide lives in another document

Customization is delegated rather than demonstrated. The template ships with V as the example persona, and the README points at a customization guide for renaming the agent across name, slug and persona, changing the AI model, adding tools and skills, configuring the Slack and Linear integrations, theming the UI, and deploying the fork. So the interesting decisions, which model, which tools, which channel wiring, are all one document away from the page that advertises them. The same pattern holds for the environment, where the full variable reference sits in `docs/ENVIRONMENT.md` and the technical detail in `docs/ARCHITECTURE.md`. Two instruction files for coding assistants sit at the root as well, `AGENTS.md` and `CLAUDE.md`, and only the first is mentioned in the README. The repository is careful about what it tells you and where. The stack underneath is named in full, Eve as the durable agent framework, Nuxt, Nuxt UI, NuxtHub for the PostgreSQL database, Better Auth, Drizzle ORM for type-safe queries and Vercel Connect for the Linear and Slack integrations, with the dependency list in package.json pinning each of them to a caret range and the shipped persona called V.

Editorial conclusion

Fork this if you want a working agent with four surfaces and a memory slot already wired, and expect to supply the infrastructure yourself. The pieces that decide whether it runs are the two Vercel dependencies the self hosting path does not remove, Neon for the database because NuxtHub is pinned to PostgreSQL with no file fallback, and a Blob store for the memory documents, plus a 32 character secret generated separately and matched across two services. Read the memory section before trusting the description, because the agent is given save and remove tools on its own profile and no approval step is described there, unlike the GitHub tools that mount with durable approval on writes. There are no releases and the version stays at 0.0.0, so a fork owns its own update path.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. vercel-labs/personal-agent-template on GitHub