01 / About
Business software should be boring to operate.
An ERP touches money, stock and payroll, so it has to be dependable for a decade. Most of the effort in running one goes not to the business logic but to the machinery around it. Sumeru is an attempt to spend that effort somewhere better.
Deployment should be a copy
If getting to a running system takes an afternoon and a wiki page, upgrades will be rare and scary. Go compiles to one binary; the only thing beside it is Postgres.
Customisation should not fork
Every business changes something. If that change means patching core, the next upgrade is expensive: so the install ages in place instead.
Your data should stay yours
The schema is the part that outlives the software. It should be plain Postgres tables that any analyst or DBA can query without learning a framework first.
How Sumeru answers that
Three tiers, cleanly separated
Module layout
The core framework, the standard business addons and your own workspace are three separate Go modules
linked by replace directives. Your customisations live in your own module. You never edit
core to add behaviour.
Addons integrate through events
No addon imports another addon. Invoicing reacts to a confirmed sales order it has no compile-time knowledge of, guarded by a registry lookup, so the same binary works whether or not Sales is installed.
Tables you can read
A model is a Go struct describing fields; the kernel turns it into a real Postgres table with real columns and indexes. Point any BI tool at it and the schema makes sense.
Conventions checked at startup
Folder name, manifest name, package name, blank imports, XML root elements and declared data files are all validated when the server boots. A malformed addon fails loudly rather than half-installing.
What we committed to
The decisions behind Sumeru
Written early so we can stick to them. Each one closes off an alternative on purpose.
| Decision | What Sumeru does | What that costs |
|---|---|---|
| Layout | Three Go modules: core, standard addons, your workspace | Three replace directives to keep pointed at the right paths |
| Linking | Addons are compiled in via generated blank imports | Adding one means regenerating and rebuilding: no runtime plugins |
| Database | PostgreSQL only, with plain readable tables | No portability to another engine |
| Schema | Derived from field definitions, synced additively at boot | No down-migrations; columns and tables are never dropped for you |
| Coupling | Addons integrate through events and registry lookups | Cross-addon flows are eventually consistent, and failures are quiet by design |
| UI | Server-rendered HTML, plain CSS, native ES modules | Less interactivity than a single-page app, and no component ecosystem |
| Isolation | One database with multiple companies inside it | Not multi-tenant. Separate customers need separate deployments |
| Conventions | Folder, package, manifest and XML shape validated at startup | The framework fails fast and gives you less freedom in how you lay code out |
| Licence | Dual: an Apache 2.0 community edition, plus a commercial enterprise edition | Some addons will not be open source, and we have to say plainly which |
The right-hand column is the honest half. If any of those costs is unacceptable for your business, Sumeru is the wrong tool.
Read the architecture next
Sumeru is the framework name in code, CLI and the repository. FAQ covers Meru vs Sumeru.