Dbrij Forge Documentation

Dbrij Forge builds a working web app from a conversation. Describe what you need, check the plan it shows you, and Forge writes the code into a Dbrij Source repository, gives it a database, and runs it on Dbrij Hosting at its own address. Then keep talking to it: ask for changes, edit the plan directly, or hand the code to a developer.

The model does not write the app. It writes a plan: what the app is, what it keeps, and what each of those things has. Ordinary code then turns the plan into the database schema, the SQL, the API routes and the pages, so the parts that must agree with each other come from one source and cannot disagree. The same plan always produces the same files.

Nothing Forge produces is locked in. The code is an ordinary repository you can clone, push to, download as a zip or copy elsewhere.

Each step records its result as it goes, so a build that stops partway says exactly where. A plan that did not finish can be tried again from the original description. A build that stops after the repository exists leaves a repository you can still clone.

Name the things the app keeps, and what each of those has. Say whether people sign in, and whether they need help or emails. A description is 8 to 16,000 characters, and the plan reads the first 12,000.

A simple CRM: clients with a company name, contact email and notes, and projects with a title, budget, stage (quoted, working, done) and a due date.

You can add a picture to plan from: a spreadsheet, a paper form, another app's screen. PNG, JPEG or WebP, shrunk to 1600 pixels on its longest side before sending, and at most 1.5 MB.

Starting points

The gallery holds ready descriptions you can start from: Bookings, Simple CRM, Inventory, Member register, Request desk. They are descriptions, not finished apps, and go through the same plan, review and build as anything you type.

A project can be built personally or inside a company.

The plan is small on purpose. It holds the app's name, a one sentence tagline, the lists it keeps, a palette, a type pairing and its capabilities.

Lists and fields

A list (Invoices, Menu items) is one kind of record, with a table, a page and a navigation item. An app has up to 10 lists and each list up to 12 fields.

Each field has a label, may be required, and may carry a one line hint. The generator adds its own columns, so a field may not be called id, createdAt, updatedAt, ownerId, paymentStatus, paymentReference, paymentToken, paidAt.

Per list options

Look

Palettes: Slate, Ink, Forest, Clay, Ocean. Type pairings: Humanist, Grotesk, Editorial. The pairings use system fonts only, so an app renders the same next year with no font files to fetch.

Capabilities switch on platform features in the generated app. Where Dbrij is involved, a credential scoped to this one app arrives as environment settings at deploy time. Credentials are never written into the code, so the repository can be shared with anyone. A capability whose prerequisite is missing never fails the build: the app serves with that part quietly off, and Forge says what is still needed.

Notification rules

A rule fires when a record is added (created) or its status changes (status), and sends by email or sms to: owner (the app owner's email), creator (whoever added the record, on a private list), a field of the record such as email or phone, or a field of a linked record such as customer.phone. The message is written from the record itself, never by a model: "New order: Kemi", or "Order Kemi is now Paid".

Payments

A list that takes payments gives each record a payment link anyone can pay through. The money lands in the app owner's Dbrij wallet, less the same fee as a form payment. The app holds a key that can only collect payments, and only for itself.

Every app is the same ordinary stack, in TypeScript:

npm install
npm run migrate     # needs DATABASE_URL
npm run dev         # the client, with /api sent to a local server

Capability files exist only when the capability is on, so no app carries code it does not use. Hosting sets these values for you; set them yourself only when you run the app somewhere else.

The code lives in a Dbrij Source repository, in your space or your company's. Every change Forge makes is a commit there with a message such as Forge: add a phone number to customers.

The app runs as a Dbrij Hosting project with two services: the app and its PostgreSQL database. Each push to the repository deploys, and the release command runs the migrations first, so a migration that fails stops the release and the previous version keeps serving. The app gets a platform address; add your own domain from Hosting like any other service.

Your first app runs as a Hosting preview for 7 days, on Hosting Free with one small database. After that its services stop unless the account is on a paid Hosting plan; nothing is deleted. Later apps run on your Hosting plan like any other service. Hosting asks for a verified card before a first deploy.

Deleting a Forge project removes the conversation and the checkpoint list only. The repository, the database and the running app belong to you and stay.

There are three ways to change a built app, and each lands as a commit and a deploy.

Edit the plan directly

The same editable plan you reviewed stays available after the build. Rename a field, add one, pick another palette: no model is called, so it costs no credits and lands in seconds.

Ask in the conversation

Say what you want changed (up to 4,000 characters) and Deputy revises the plan, which is regenerated, committed and deployed. This spends AI credits. The plan covers what the app stores, so adding, removing and renaming things works this way; wording, layout and behaviour go to the code agent.

The code agent

For changes the plan cannot express, the code agent reads the code, writes edits, checks them and commits. Hosting's build is where the code runs, never Dbrij's own servers. Before it starts you get a quote: what a change like this usually costs and a ceiling. It stops before any step that could pass the ceiling you agreed to, and a higher price at start time is refused. If the build fails after its change, it tries to fix it once within the same price. A first agent change moves the app to code mode (see Continuing by hand).

Your data is safe across changes

• A schema change becomes a new numbered migration; migrations already run are never rewritten.
• New tables and columns are added only when missing, so the same file is right on a fresh database and an old one.
• Nothing is ever dropped. A field you remove disappears from the app, and its column stays in the database, unused.
• Changing a field's type converts existing values. If a value cannot convert, the migration fails, the release fails, and the previous version keeps serving.

While an app is still building, or while the code agent is working on it, other changes wait.

Forge saves a checkpoint for every change it makes. Each is a real git tag in the repository (checkpoint-001, checkpoint-002, and so on), so it can be reached with ordinary git as well as from Forge.

git fetch --tags
git checkout checkpoint-003

Putting a checkpoint back makes a new commit with that version's code, and deploys it; history is never rewritten. In code mode you can also save where the code stands as a checkpoint of your own; a checkpoint holding code written outside Forge is marked as such.

Turn the preview on and every change lands on a copy of the app with its own copy of the data, at its own address. Customers keep the published version until you publish. Turn it off and changes go straight to customers again.

Publishing runs a security check on the exact preview build first:

Publish anyway applies to the commit you accepted it for, and never past critical. Hosting's own Promote button for a Forge app follows the same rule.

The repository is yours: clone it from Source, change anything, and push. Each push deploys like any Hosting service.

npx dbrij login && npx dbrij git setup
git clone https://api.dbrij.com/git/<owner>/<app>.git

Code mode

When Forge sees commits it did not write, the app moves to code mode. Forge keeps saving checkpoints, deploying, rolling back and publishing, and it never rewrites your files. Conversation and plan edits wait, because regenerating would overwrite your work. To change it by conversation again, put back a version Forge wrote from Checkpoints. The code agent works in code mode too.

Export

• Download the code as it stands as a zip.
• Copy the code, its history and its checkpoints to a new repository on your connected outside git account, private unless you say otherwise.

Nothing in the code is proprietary. Hand it to a developer, keep deploying it on Dbrij, or run it anywhere Node and PostgreSQL run.

What costs credits

Planning a new app and asking for a change in the conversation spend AI credits; Forge shows the usual figure before you press either. Code agent changes are priced by their quote. Building, deploying, editing the plan yourself and putting a checkpoint back call no model and cost nothing.

One app to try

Without a Forge subscription you can build one app in your personal space. It comes with 200 starter credits to plan it and ask for a few changes (granted once per person) and the 7 day Hosting preview. Every other project needs Forge.

Daily limits reset over a rolling day, and every app keeps running in the meantime.