All modules
modules · packs

A pack is
many modules,
wired as one.

A pack is built like any other module — but it declares several of them as dependencies, installs them together in one step, and ships the glue that makes them work as a single application.

what it is

Built like a module,
scaled to a system.

Install a single module and you get one capability — CRM, say. A pack is shaped the same way — the same metadata — but it declares several modules as dependencies and pulls them in together.

And it isn't only a bundler. Like a bridge module, a pack can ship its own functionality — extensions and bridges that join its modules so they act as one rather than side by side. Everything else in the catalog is a single module you add on its own.

what's inside

One entry,
everything wired.

A pack is a manifest, not a monolith — it pulls in real modules and adds the integration that connects them, so what installs is a working, joined-up app.

[dependencies]
Module dependencies

A pack declares the modules it's built on — each one the same standalone module you'd find on its own in the catalog.

[integration]
The glue

Bridges and extensions the pack ships itself — quote-to-invoice, shared views — joining its modules so they work as one system, not side by side.

[install]
One-step install

Resolve once, install once. No installing several modules in the right order and wiring them together by hand.

[versioning]
Versioned as a set

The pack pins compatible versions of its modules and moves them forward together, so the bundle always composes cleanly.

[metadata]
Built like a module

No new kind of thing: a pack is the same metadata format as any module — it just composes others and adds the layer between them.

[extend]
Extend, don't fork

A pack is a starting point. Add modules, write extensions, bridge in your own — without forking anything it shipped.

an example

The ERP Suite,
broken open.

One catalog entry — "ERP Suite" — pulls in four modules and the bridges between them in a single step. Here's what's actually in the box.

// packERP Suite[crm]Sales[fin]Finance[wms]Warehouse[hr]HR// resultInstalls and runs as one application4 modules · 3 bridges · 1 install
/ module dependencies
[crm]
Sales

Leads, quotes, orders.

[fin]
Finance

Invoices, payments, ledger.

[wms]
Warehouse

Stock, picking, fulfilment.

[hr]
HR

People, roles, time off.

Plus the bridges the pack adds itself — Sales↔Finance for quote-to-invoice, Warehouse↔Sales for fulfilment — so the four behave as one connected system instead of four silos.

pack vs module

Which one
am I installing?

PackSingle module
ScopeA whole area — several modulesOne capability
InstallsIts module dependencies + glue, in one stepJust itself (and its dependencies)
IntegrationShips the bridges that join themYou add bridges as needed
ExampleERP SuiteCRM
Reach for it whenYou want a whole area stood up and joinedYou want exactly one capability

Under the hood it's the same metadata — a pack is a module that depends on others and supplies the glue between them. The difference is just how much it stands up at once.

// get started

Browse the
catalog.

Packs and single modules live side by side — packs are marked. Pick a starting point and install.