forgedb init

Scaffold a new ForgeDB project — schema, config, gitignore, and the deploy files that drive the CLI.

Scaffold a new ForgeDB project directory: a starter schema.forge, a forgedb.toml, a .gitignore, a README.md, and the container + systemd deploy files.

init scaffolds no cargo package. There is no Cargo.toml and no src/main.rs, because the generated Rust is compiled in ForgeDB's own build cache — forgedb build prints where the artifacts landed. The generated server binary is one of those artifacts; you do not own a crate that produces it.

Synopsis#

forgedb init <project_name> [--template <name>] [--isolated | --no-isolated]

<project_name> becomes the new directory; init refuses to run if it already exists.

Flags#

Flag	Type / default	Meaning
`<project_name>`	string (required)	Project directory to create.
`-t`, `--template <name>`	string (blank)	Starter schema: `blog`, `ecommerce`, `todo`, or `blank`. An unknown value falls back to `blank` with a warning.
`--isolated`	bool	The new schemas form their own project, even inside an existing one.
`--no-isolated`	bool	Join the enclosing project, sharing its build cache and lockfile.

With neither grouping flag, init joins an enclosing project when it finds one and reports which — scaffolding inside an existing project is how you add an app, not an error. See [project].

--rust and --api-only were removed

Both selected a generation target, which is now declared once in forgedb.toml as [generate].targets. Passing either is an error naming the key, rather than a flag that reads as applied and is not. targets is required, and ["all"] is what init writes.

What gets created#

my-app/
  schema.forge          starter schema (from --template)
  forgedb.toml          [project], [generate].targets, and the runtime knobs
  .gitignore            generated/ is COMMITTED; data/ and *.a are not
  README.md
  generated/            written by `forgedb generate`
  data/db/ data/wal/    the app's data directory
  Dockerfile            multi-stage, installs the pinned CLI and runs it
  .dockerignore
  docker-compose.yml
  deploy/app.service    systemd unit
  deploy/app.env
  deploy/README.md

The deploy files drive the CLI, not cargo

The Dockerfile copies your schema and forgedb.toml, installs a pinned forgedb, then runs forgedb generate + forgedb build and copies out the path forgedb build --print-artifact server reports. It never runs cargo build on a crate of yours, because there is no crate of yours.

generated/ is committed

The scaffolded .gitignore no longer ignores /generated/ wholesale. That directory is source you review and ship — database.rs, api.rs, types.ts, openapi.json, the client SDKs, the Go package, and the binding shims. The compiled artifacts forgedb build delivers are ignored by a .gitignore ForgeDB writes inside the output directory, not by this one: the patterns would have to name that directory, and output is a per-app setting.

Examples#

Scaffold a blog project and build it:

forgedb init my-blog --template blog
cd my-blog
forgedb generate
forgedb build

Add a second app inside an existing project (sharing its cache and lockfile):

forgedb init reporting --no-isolated

Next steps#

Edit schema.forge — see the schema language.
Run forgedb generate to produce code.
Configure runtime behavior in forgedb.toml — see configuration.

Synopsis#

Flags#

What gets created#

Examples#

Next steps#

Search documentation