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"
}Connect two modules.
A bridge module like crm-fin depends on both CRM and Finance and owns the integration between them — quote-to-invoice conversion, shared views — with no entities of its own.
It's built from extensions, so neither base module is forked. Anyone can bridge any two modules; install the bridge only when both are present.
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. However a module was authored, the output is just a regular dForge module.
Adapt a module without forking it.
An extension adds fields, actions, reports and settings to entities owned by another module — a Swiss invoice variant, your company's fields on a community CRM. Your changes live in your own module and ride upstream updates. Stack as many as you want; you can even extend modules you didn't write.
Module extensionsThree 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 write it.
Same output, three paths in. AI-assisted authoring for the fastest results; schema import for legacy migration; or hand-author the module files in your editor with the dForge extension.
Connect the dForge MCP server, open 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.
Write and edit module files directly in VS Code with the dForge extension — DSL syntax highlighting and JSON-schema validation across every file, with errors inline as you type. Zed highlighting is available today; more editors follow.
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 |
| Editor extension | ✓ (VS Code) | ✗ | ✗ | ✗ |
| 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.