Project structure

bever new creates three folders and a few files:

my-app/
  bev/
    app.bev                 your model; split it into more .bev files with Export and Import
    schema.snapshot.json    the accepted database schema (created by the first migration)
    migrations/             one JSON file per database change
    .output/model.json      the compiled model (generated; not committed)
  client/                   the web app (Nuxt 4, Vue, Tailwind CSS, shadcn-vue)
  server/                   the API (ASP.NET Core 10)
  .bever/                   the local SQLite database and sign-in keys (not committed)
  Dockerfile                one production image for app and API
  docker-entrypoint.sh
  README.md

bev/

Every *.bev file under bev/ is part of the model. The compiler reads them in name order and treats them as one program, so an entity in customers.bev may reference one in orders.bev.

Commit schema.snapshot.json and migrations/. They record how the database evolves and let every environment reach the same schema. .output/ is regenerated by bever compile and bever dev.

client/

A standard Nuxt app in single-page mode:

client/src/
  app.vue                 the shell: sidebar, mobile navigation, sign-in state
  pages/                  routes: home, sign-in, and /<entity>, /<entity>/new, /<entity>/<id>, /<entity>/<id>/edit
  components/             record table, forms, reference pickers, sign-in panel
  components/ui/          shadcn-vue components
  bever/                  helpers that read the model and talk to the API
  assets/index.css        theme variables (colors, radius, font)

The pages read the compiled model at build time, so adding an entity adds its pages; you do not regenerate anything. During development the dev server proxies /api to the server, so the app and the API share one origin exactly as in production.

server/

A standard ASP.NET Core app. Program.cs adds Bever and maps its API:

builder.Services.AddBever();
// ...
app.MapBeverApi();

It also keeps sign-in keys in .bever/keys, limits sign-in attempts, and serves the built client from wwwroot in production. Everything else is yours to change.

Where data lives

Path	Contents
.bever/bever.db	SQLite database: your records, plus private tables for accounts, roles, and grants
.bever/keys/	Keys that encrypt sign-in cookies; keep them to keep people signed in

In production both live on a persistent volume. See Deployment.