project.cfg schema

project.cfg is the per-project config, read by the client commands (sync, build, bundle, validate). It is RON, lives in the project folder, and is optional — a missing file means all defaults.

(
    publish: ( server: "https://pad.example.com", site: "my-site" ),
    build: ( command: "npm run build", output: "dist" ),
    routing: (
        clean_urls: true,
        redirects: [ (from: "/old/:slug", to: "/new/:slug", status: 301) ],
    ),
)

Sections:

publish

See also the separate apply.cfg project manifest, which declares a whole project — its member sites, top-level functions, compute workloads, managed databases, and tenancy schema — as one applied unit. Its field-by-field schema is below.

build

Run before sync; its output directory is what gets published.

bundle

The in-process bundler (Rolldown for JS/TS, lightningcss for CSS). Needs the bundler feature.

routing

The bulk of a project’s config: redirects, rewrites, headers, SPA fallback, clean URLs, error documents, and the handler/consumer/cron/stream declarations. It is compiled and checked at sync (and by boatramp validate), then folded into the immutable deployment manifest — so it is atomic with the content and rolls back with it.

The full field-by-field schema is on its own page: Routing config schema.

Validate a project.cfg (including routing) without publishing:

boatramp validate

project.cfg: routing OK (2 redirects, 1 handler)

apply.cfg manifest schema

apply.cfg is a separate, project-level RON manifest read by boatramp apply. Where project.cfg configures one site’s publish, apply.cfg declares a whole project — its member sites, top-level functions, compute workloads, managed databases, and tenancy schema — and reconciles it as one applied unit. It is upsert, never prune: apply create-or-replaces only the resources it names and never deletes anything absent from the manifest, so declarative and imperative management coexist.

Unlike project.cfg, a missing manifest is an error (there is nothing to apply). The default filename is apply.cfg (-f overrides it).

Manifest top-level fields

The whole document is parsed with deny_unknown_fields, so a typo or an excluded key fails to parse rather than being silently ignored.

version + migration

The optional top-level version: <u32> opts a document into the migration framework (v0.6.0):

• Absent (or equal to the current schema) ⇒ parsed strictly against the current typed schema. An old-shaped manifest that omits version fails with an upgrade error naming the migration path (the most common cause is a pre-v0.6.0 raw-JSON compute[].spec).
• version: N older than current ⇒ the document is run through the registered migration chain (vN → … → current) via boatramp config migrate <file> (--write rewrites in place), then parsed strictly. An upgraded/migrated manifest omits version: (current = absent).
• version: N newer than this build understands ⇒ rejected.

Declare the schema you wrote against to get migration support; omit version: and your manifest is parsed as current. Add version: 1 (the pre-v0.6.0 schema) only when upgrading an old manifest with config migrate.

The manifest is authored in RON. As of v0.6.5 a JSON manifest is also accepted for interop (current schema only — a JSON document is not run through the migration chain); RON stays the canonical authoring format. See the config formats how-to.

compute workloads (ComputeSpec)

Each compute[] entry is a workload name plus a typed spec (v0.6.0 — before this, spec was a raw JSON blob; it is now the typed ComputeSpec, so a malformed spec fails at parse time). It mirrors the server’s PutComputeRequest:

ComputeSpec key fields:

RootSource

A tagged, snake_case newtype variant selecting the root FS form (matched 1:1 to the backends that accept it):

compute: [
    ( name: "api",
      spec: ( root: image("ghcr.io/acme/api:1"), vcpus: 1, mem_mib: 512, port: 8080 ),
      replicas: 2 ),
]

Managed databases (databases)

The databases: block (v0.6.0) is the declarative front door onto boatramp’s managed-database provisioning — the SOLE authoring surface for a project-scoped managed DB (there is deliberately no imperative db create; a create verb would compete as a second source of truth). Declaring an entry no longer requires an operator to hand-edit boatramp.cfg — a project author adds an entry and runs boatramp apply.

Each ApplyDatabase is a typed, SAFE projection of the node-static external database config, restricted to the fields a project author may safely declare. Reconciled before sites/functions/compute, so a handler shipped in the same apply binds an already-provisioned DB. It is PUT-only (create-or-replace + eager provision); removing an entry NEVER deprovisions the database, volume, or credential (teardown stays an explicit imperative verb — a data-loss guard).

Excluded — the security contract. These are not fields; a manifest that names one fails to parse (deny_unknown_fields), because the credential is minted + sealed server-side and never lives in a committable manifest:

Semantics. Declaring a database mints owner-role identities, so the declare + provision route is Project·Admin-gated (the same owner-grade placement as migrate/repair — a project publisher/deployer can never reach it). A declared database is persisted project-scoped at project/{project}/database/{name} and MERGED with the node-static [handlers].bindings.sql.databases map at one resolution point where daemon-static config WINS, fail-closed, on a same-name conflict — a project manifest may never shadow or downgrade a node operator’s bring-your-own binding. Two operator ceilings guard the node’s disk: max_declared_databases (count, default 16) and max_declared_volume_mib (aggregate volume, default 512 GiB), enforced fail-closed at declare (a 422).

Read-only inspection is boatramp db ls | get <name> | status <name> (CLI reference); there is no db create. See the apply how-to for the end-to-end flow.

databases: [
    ( name: "app", kind: postgres, version: 16, size: medium,
      tenant: shared, tenant_scope: project, extensions: ["pgcrypto"],
      rls_session: true, tenant_guc: "app.tenant_id" ),
]