di-sukharev/vibe: a full stack Bun starter that asks questions before it clones

One repository, four runtimes and a locked Bun version

The template is a Bun workspace, not a bare starter. The `package.json` declares `packageManager` as `[email protected]`, sets the package name to `vibecoding-template`, marks itself private at version 0.0.0, and lists four workspaces: `webapp`, `website`, `backend` and `packages/*`. There is a `bun.lock` and a `.bun-version` at the top level, so the lockfile is meant to be regenerated with a pinned Bun rather than whatever version happens to be on the machine.

The README describes what each workspace is for. `backend/` is a Bun and Hono server, `webapp/` is a React client-side rendered browser app, `website/` is an Astro site that can be static or server rendered, and `packages/` holds the shared API contracts that both sides import. The runnable Expo mobile template lives on a separate `mobile` branch so that the default branch stays focused on web work, which is a deliberate choice rather than an omission.

The tree also carries `AGENTS.md`, `CLAUDE.md`, `CHECKLIST.md`, `NOTICE`, `docker-compose.yml`, `docs/`, `infra/`, `scripts/` and `bunfig.toml`. That is a lot of instruction files for a starter, and they are the point. The project is Apache-2.0 licensed, is not archived, and the default branch `master` was last pushed on 2026-09-13. The listed homepage is `vibe.sukharev.dev`.

CHECKLIST.md as an intake gate before feature work

The README's first substantive section is a rule, and it is the reason this template behaves differently from most. `CHECKLIST.md` is described as both the intake questionnaire and the durable record of what the project needs. An agent is told to ask its questions in the user's language and in product terms, then write the answers into that file. No feature work starts until everything through the section called _First-version capabilities_ is filled in, along with every conditional section those answers activate.

One question comes before cloning, because it selects a branch: does the project need a mobile app now. Everything else runs inside the fresh checkout, where the file can be edited.

There is also a list of things the agent must not do. It is not allowed to hand the user the options listed under _Decided by the agent_, because those are the agent's calls to make and explain, including the `webapp` versus `website` split. Once answers exist, they are written back into the file: project name and slug, which surfaces are active and which are deferred, the first version capabilities, the capability ledger, and the deployment decision. A checklist kept in a file survives the session. The same answers held only in a chat transcript do not.

The exact prompt the README hands to a fresh agent

The template is written for agent installation, so the README supplies a prompt verbatim rather than paraphrasing the setup. The opening block looks like this:

Install this repository into the project. Before cloning, ask whether I need the mobile app now;
use the mobile branch only when I do, and run its published-template gate before setup. Read
README.md, CHECKLIST.md, AGENTS.md, and the docs for every active surface. Run the CHECKLIST
intake in my language and record every durable answer before feature work.

The rest of that prompt covers the parts people usually get wrong. Treat the checkout as a new project unless the user says they are contributing to the template, which means inspecting git remotes and detaching the template remote. Use Docker Compose for local PostgreSQL and do not require cloud credentials for local work. Never deploy from a dirty, detached, unpushed or wrong branch. After setup, remove the marked Bootstrap-Only Instructions block from `AGENTS.md`, validate the active surfaces, and report the remaining account and domain authorizations without printing secrets.

The remote handling is concrete about the mechanics. `git remote -v` is inspected before any branch, commit, push or PR work. If `origin` points at the template and the user has not said they are improving the template, the checkout is treated as a new project and the remote comes off with `git remote remove origin`. A user-supplied repository URL is added as the new origin only when they provide one; otherwise the repository is left with no remote and the agent reports that publishing is not configured. Pull requests against the template repository are not opened during setup.

Local PostgreSQL on a pinned port with an optional S3 stand-in

Local development runs on Docker Compose, and the compose file is specific about how. PostgreSQL 18 on Alpine comes up with the database named `web_app_demo`, a superuser, and a port bound to loopback:

postgres:
  image: postgres:18-alpine
  restart: unless-stopped

The port mapping defaults to 54329 and the test database to 54330, both bound to `127.0.0.1` so nothing is exposed to the network. Each has a healthcheck running `pg_isready` against its own user and database, which is what lets dependent steps wait for a usable server instead of retrying blindly.

Storage is where the file is opinionated, and the comments explain why. The default storage driver is `filesystem`, which keeps uploads on disk with no container involved. An optional S3-compatible service, SeaweedFS on version 4.41, exists purely to exercise the real S3 path, and its command deliberately leaves versioning and object locking off because the comment states SeaweedFS mishandles conditional writes when they are enabled, and conditional writes are what make an upload key write-once. The credentials in that block are described in the file itself as literal and obviously fake. The README reinforces the production rule: managed PostgreSQL and private object storage for production media, never a container filesystem for durable uploads.

Picking one Terraform provider and deleting the other

Infrastructure lives under `infra/` as Terraform, and the provider decision is made once from a fact the checklist records: where the users are. Russia or a data residency requirement means Yandex Cloud, with a runbook at `docs/YANDEX_CLOUD.md`. Anything else means DigitalOcean, with `docs/DIGITALOCEAN.md`. An explicit wish for full control means your own server. The README is unambiguous that a project should keep one of these, not two: in an installed project you delete the unused provider directory and runbook rather than carrying two possible production states.

Every infrastructure action is a `bun run` script with the provider as an argument:

bun run infra:bootstrap -- <provider> --new
bun run infra:apply -- <provider>
bun run infra:plan -- <provider>
bun run release -- <provider>

Bootstrap creates state once, apply is reserved for deliberate foundation changes, plan inspects, and release deploys the release-owned surfaces. The prompt the README supplies also tells the agent to copy the bootstrap and production `terraform.tfvars.example` files, fill in project values, keep secrets uncommitted, and follow `docs/DEPLOYMENT.md` together with the selected provider runbook.

The mobile branch has its own gate. If `mobile` is active, the README says to clone the full repository, switch to `mobile`, fetch both refs, install the locked dependencies, and run `bun run mobile:template:check -- --published` before first-run setup, stopping if the command is missing or fails.

Renaming without leaving half the template behind

Every scaffold that names itself has the same problem, and this one has a documented procedure. The README asks for a deliberate rename rather than an unreviewed global replacement, starting with an inventory search:

rg -n "web_app_demo|web-app-demo|vibecoding-template|Vibe Coding Template"

The stated targets are package scopes, database names, cookie names, Docker and Compose isolation names, deploy image defaults, architecture-check aliases, and the page title in `webapp/index.html`. Each owning source is updated, `bun.lock` is regenerated with the pinned Bun version, and then install, typecheck, architecture checks, backend integration and web end-to-end runs all execute for the active surfaces.

That list of checks is visible in the root `package.json` too. The `check` script chains template checks, architecture checks, an audit, typecheck, lint and tests, and there are narrower scripts for each workspace:

"dev:webapp": "bun run --cwd webapp dev",
"dev:website": "bun run --cwd website dev",
"dev:backend": "bun run --cwd backend dev",

The root also has parallel and sequential fan-out scripts, a `dev:seed` script that runs the backend Prisma seed, a `dev:backend:s3` script for local object storage, and per-workspace build scripts. The `overrides` block pins shared transitive dependencies, which is how a template keeps two workspaces from drifting apart on the same package.

Editorial conclusion

vibe is aimed at someone who wants an agent to start building on day one rather than spend a week on setup, and the parts that make it unusual, the CHECKLIST.md intake, the instruction to run `git remote remove origin` so commits do not land upstream, and the rule that a project keeps only one Terraform provider directory, all address failures that are easy to hit and tedious to undo. It is a poor fit if you want a bare skeleton with no opinions, or if your product is not a Bun and PostgreSQL web application. Two things to check first: whether you need the mobile app now, because that question selects the `mobile` branch and its published-template gate has to pass before setup, and which audience you are building for, since hosting is fixed from data residency. Clone it, fill in CHECKLIST.md, then run `bun run check` before writing features.

Frequently asked questions

Official sources

1. di-sukharev/vibe on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README