From definition
to production.
Governed every step.
A dForge app is defined as metadata — versioned, diffable, reviewed. That definition is promoted through dev, test and staging into prod through a real lifecycle, with gates and an audit trail at every hop. No visual designer where one click breaks production.
Five steps,
one definition.
From what the business needs to a running app — every step works on the same definition, and nothing is hand-edited in production.
Capture what the business needs as a data model: entities, fields and the relationships between them.
Shape how it behaves: views, roles, actions and the rules that govern who can do what.
Author the module as metadata — in VS Code or with AI. Every save is validated against JSON-Schema.
Apply it to an isolated test tenant with seed data. Run checks, migrations and policy assertions first.
Promote through staging into prod with zero downtime — and the previous version stays one command away.
Don't be scared
to break things.
A test tenant is a throwaway copy — isolated, seeded, resettable. Spin one up, throw your worst at it, then wipe it clean. Nothing you do there can reach a real user, so experiment without fear; only what survives the gates ever ships.
- › test tenants are fully isolated from production
- › clone real structure and seed data in seconds
- › break whatever you want, then reset to a clean slate
- › prod only ever sees changes that passed the gates
$ dforge tenant create test --from prod --seed
✓ isolated tenant ready · acme-test.dforge.app
# rename a field · drop a table · break a workflow — go wild
$ dforge tenant reset test
✓ wiped & reseeded in 9s · production untouchedEvery change is
a reviewable diff.
Because the app is metadata, a change is a diff a human can read and approve — not an opaque click inside a designer.
- › the definition is the spec — one source of truth
- › the diff shows exactly what changes: a field, a role, a step
- › approve it in a pull request before it merges
- › every version is tagged, attributable and reversible
entity Lead { name text required stage enum new | qualified | won+ priority enum low | normal | high- legacy_code text owner ref(User)}Full version control,
in your own git.
Module definitions are plain text files. Commit them to your own GitHub, GitLab or Bitbucket — branch, tag, open pull requests, run CI. The whole history of your app lives in version control, every change tied to a person and a commit.
- › definitions are plain text — diff- and merge-friendly
- › bring your own GitHub, GitLab or Bitbucket
- › branches, tags and pull requests, the way you already work
- › run dforge validate in CI on every push
$ git checkout -b feature/lead-priority
# edit lead.module …
$ dforge validate
✓ 0 errors · 0 conflicts
$ git commit -am "add lead.priority field"
$ git push → PR #142 → CI: dforge validate
✓ checks passed · ready to mergePromote between
environments — with gates.
Moving to the next environment runs preflight checks. A failed gate stops the promotion — it never half-applies to a live tenant.
- ✓ schema migration is reversible
- ✓ no breaking removals of fields in use
- ✓ role & policy assertions pass
- ✓ all tests green on staging
$ dforge promote staging → prod
running preflight…
✓ migration reversible · 1 added, 1 removed
✓ no breaking removals · legacy_code unused
✓ role & policy assertions · 9 passed
✓ staging tests · 142 passed
promoting v2.4.1 → prod…
› live in 38s · zero downtime · acme.dforge.appRoll back in
one command.
Every promotion is a versioned artifact. If prod misbehaves, roll back to the previous version instantly — data intact, audit trail kept.
A real lifecycle.
Not a live-edit designer.
| dForge | Visual low-code | Hand-coded | |
|---|---|---|---|
| Separate dev / test / stage / prod | ✓ | ✗ | ✓ |
| Changes are reviewable diffs | ✓ | ✗ | ✓ |
| Promotion gates / preflight checks | ✓ | ✗ | build it |
| One-command rollback | ✓ | ✗ | build it |
| Edits never touch prod live | ✓ | ✗ | ✓ |
| Full change audit trail | ✓ | limited | build it |
| No application code to maintain | ✓ | ✓ | ✗ |
Define it once.
Ship it safely.
Open a free workspace and walk a change from definition all the way to production yourself.