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, Studio 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 Studio or YAML metadata. Keep them private to your tenant, or publish them across your organization.
Click it,
or commit it.
Same output, two paths in. Visual designer for analysts and consultants; package format for dev teams who want everything under git.
Browser-based designer. Define entities, views, menus, roles, actions, triggers — point, click, validate, publish. No CLI, no code files, no deployment pipeline.
A folder of JSON and DSL files: manifest.json, entities/, ui/, security/, logic/. Versioned in git, packaged as a .dforge file, installed via CLI or API.
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-friendly authoring | ✓ | limited | ✗ | limited |
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. Pick a module that looks close to what you need, install it, and reshape it in Studio if it isn't quite right. The fastest path to a working app is the one that already exists.