One origin, many applications
Modules used to live on their own subdomains — accounting.erp.io, crm.erp.io, and so on. They have been collapsed onto paths of a single origin: app.erp.io/accounting, app.erp.io/crm. The old subdomains still answer and redirect, permanently, with the path and the query string preserved.
| Module | Mount | Old address |
|---|---|---|
| Accounting | /accounting | accounting.erp.io |
| CRM | /crm | crm.erp.io |
| Projects | /pm | pm.erp.io |
| Marketing | /marketing | marketing.erp.io |
| Phony | /phony | sdr.erp.io |
| Chat | /chat | chat.erp.io |
| PLM | /plm | plm.erp.io |
| Sign | /sign | sign.erp.io |
| CFO | /cfo | cfo.erp.io |
| Canvas | /canvas | canvas.erp.io |
| Legal | /legal | legal.erp.io |
| Client Portal | portal.erp.io | — not collapsed |
What one origin buys
- One session cookie. A module that has never seen you can tell the suite already has, and sign you in without asking.
- No cross-site hand-off. Browsers are increasingly hostile to third-party cookies and cross-site redirects. There is no cross-site anything here.
- Same-origin data. One module reading another is a plain fetch, not an integration.
- One bookmark. People remember
app.erp.ioand navigate by the rail. - One certificate, one WAF policy, one set of security headers.
The cost is that a path is global to an application, so mounting a module rewrites every URL it generates. That is invisible when it is right and produces a specific, recognisable class of bug when it is wrong — a link that drops the mount and lands on the shell. If you ever see a module link take you to the shell home page, that is what happened, and it is worth reporting with the URL.
The exception: Client Portal
The Client Portal is deliberately not collapsed onto a path. It answers on eleven hostnames — portal.erp.io plus ten account.<brand> domains that clients sign in to — and a path mount is global, so mounting it would rewrite every one of those brand addresses at once and break every bookmark and emailed link a client holds.
The reason to collapse a module is a session cookie shared with the shell, and the portal's users are clients who never touch app.erp.io. So the trade does not apply. That decision is revisited only if the portal can be deployed twice from one image with the mount driven by configuration.
One origin, three applications
Independent deployment
Each module is its own application with its own database and its own release cadence. A change to Accounting does not rebuild Chat. Modules do not share tables and there are no foreign keys across them — where two modules need the same fact, one asks the other over HTTP and holds a copy.
A module failing is not the suite failing. The rail still renders, other modules still work, and the failure is scoped to one path. It also means "is erp.io down" is usually the wrong question — the useful one is which path.
What this does not do
The suite is hosted. There is no installable build.
Everything runs in one region today. Data residency is not selectable.
There is a single status surface, not one per module.
Questions
Are the old subdomains going away?
They redirect permanently and there is no plan to remove them. Bookmarks keep working.
Can we self-host one module?
No. Modules depend on the shell for identity and are not distributed separately.
Do modules share a database?
No. Each has its own, with no cross-module foreign keys.
Related
How erp.io signs you into a module without a second login: the hand-off token, what the module verifies, and why a module can still ask you to sign in.
Client PortalWork orders and a client-facing workspace in erp.io — the only module that answers on your own brand domains, and the only one clients sign in to.