Architecting Multi-Tenant SaaS ERP That Also Runs On-Prem

Enterprise software buyers rarely agree on deployment. Some want the convenience of multi-tenant SaaS; others — especially regulated organizations — insist on single-tenant, on-prem control. Maintaining two codebases to serve both is a trap. For our multi-tenant HRMS, we built one platform that does both.

Tenant resolution up front

Every request first resolves which tenant it belongs to — by domain or subdomain — before any business logic runs. In SaaS mode that selects the right isolated data context; in single-tenant mode it resolves to the one tenant. The rest of the application doesn't need to know which mode it's in.

Pluggable authentication per tenant

Enterprises don't share an identity provider. So auth is an orchestrator, not a single strategy. Per tenant, it supports:

• Local accounts
• LDAP / Active Directory
• External database authentication
• Hybrid combinations

On success it issues Sanctum tokens and applies full role/permission RBAC. Adding a new login mechanism is a matter of plugging in a new strategy, not rewriting the login flow.

One auth orchestrator, many strategies — so each tenant logs in the way its IT department requires.

Security that assumes multi-tenancy

• Encrypted tenant secrets, isolated per tenant
• Audit logging for authentication and role changes
• RBAC enforced through a middleware chain, consistently across every route

Why one codebase wins

Supporting SaaS and on-prem from a single codebase means every security fix, feature and integration ships to all deployment modes at once. There's no "on-prem is three versions behind" problem — which, for HR and payroll data, is exactly the guarantee customers need.

This architecture now informs how we approach any product that has to straddle cloud convenience and enterprise control.