A module is
an entire app
made of metadata.
In dForge, a module is a self-contained package that becomes a real, running application the moment you install it. Tables, forms, security, business logic — all declared as JSON, all editable without redeploying, all composable with every other module on the platform.
Not a component.
A complete app.
Most platforms call something a "module" when it's really a library, an extension, or a configuration toggle. In dForge a module is the unit of value — install one and your tenant gets a working CRM, or HR system, or warehouse tracker, complete with database tables, role-based access, screens, workflows, and seed data. No glue code. No deployment.
This is what makes the catalog at /modules feel different from a "marketplace" — every entry is a finished product, not a snippet you have to wire up.
Six things in,
one app out.
Open any module package and you'll find the same shape — six kinds of metadata that the platform reads at runtime to behave as a working application.
Tables, columns, types, constraints, traits, references, sets, formulas, generated aggregates. The data model — declared, not coded.
Grids, kanbans, lists, calendars, timelines. Each view is a saved configuration over one or more entities, with column overrides per folder.
Navigation tree and the folders the module ships with. Folders are dynamic filtered views, not containers — same record can live in many at once.
Module-namespaced roles (crm.sales_rep, hr.manager) with letter rights — S, I, U, D, C, E. Additive, folder-scoped, no implicit access.
Server-side DSL scripts with params, canExecute, and execute blocks. Triggers fire actions when records change. All sandboxed, all auditable.
Configurable values overridable per folder, plus localized labels for every entity, field, menu, and action. Reference settings in formulas via $[Name].
Modules compose.
No fork required.
Modules declare what they need.
Every module's manifest.json lists the other modules it depends on. admin is always required. The rest you opt into.
"dependencies": {
"admin": ">=0.0.1",
"crm": ">=0.5.0",
"fin": ">=0.5.0"
}Extend without modifying.
A bridge module like crm-fin can add quote-to-invoice conversion by extending entities from both CRM and Finance — without forking either one.
Extension columns live in a separate 1:1 table; the query builder JOINs them automatically. Upgrade either base module and your bridge keeps working.
Each tenant picks its stack.
Modules install per tenant, not platform-wide. One tenant might run CRM + HR; another runs Finance + WMS + a custom module. There is no shared schema — every tenant has its own database.
One engine for everything.
System modules, community modules, and your own custom modules all run on the same metadata engine. Same security model, same DSL, same UI. There's no "Studio mode" runtime — the output is just a regular dForge module.
Three tiers.
One runtime.
Maintained by dForge. CRM, HR, Finance, WMS, Pricing and more. Regularly updated, fully supported, guaranteed to compose.
Specialized industry packs, regional compliance, integration connectors. Built by partners and the wider community. Same metadata, same runtime.
Build your own with AI or hand-author JSON metadata. Import from existing databases. Keep them private or publish across your organization.
Say it,
import it, or click it.
Same output, three paths in. AI-assisted authoring for the fastest results; schema import for legacy migration; visual designer for point-and-click editing.
Run npx @dforge/create-module, open in Claude Code with the built-in skill. Describe what you need in plain language — the AI handles field types, conventions, FK patterns, DSL actions, and validation. Review the output, package, install.
Have an existing database? Feed your SQL or DBML into the schema importer. It infers field types, detects relationships, and produces a rough-cut module. AI finishes the ambiguous parts. Your legacy data migrates with it.
Browser-based designer. Define entities, views, menus, roles, actions, triggers — point, click, validate, publish. No CLI, no code files, no deployment pipeline.
Why metadata
beats code.
| capability | dForge module | Odoo addon | SaaS app | Custom microservice |
|---|---|---|---|---|
| Format | Metadata (JSON) | Python code | Closed binary | Code |
| Real database tables | ✓ | ✓ | hidden | ✓ |
| Install per tenant | ✓ | ✓ | ✗ | build it |
| Edit without redeploy | ✓ | ✗ | ✗ | ✗ |
| Bridge / extend other modules | ✓ | limited | ✗ | build it |
| Visual designer | ✓ (Studio) | ✗ | config UI | ✗ |
| Self-hosted | ✓ | ✓ | rare | ✓ |
| AI-native authoring | ✓ (skill + importer) | limited | ✗ | limited |
| Legacy schema import | ✓ (SQL / DBML) | ✗ | ✗ | manual |
This isn't a knock on Odoo or microservices — they have their place. It's a different bet about where the leverage is. dForge bets that most business logic looks the same across companies, and what differs is the configuration. Make the configuration the program, and you ship in days.
Browse what's
already built.
Start with the catalog or build your own. Describe it to AI, import your existing schema, or browse what's already built. The fastest path to a working app might already exist — and if it doesn't, you can create one in minutes.