The platform under every NXHub module.
Prime, Pay, Shield, RIO — every product runs on the same multi-tenant rails. One codebase, isolated tenants, governed schemas, and capabilities you turn on per building.
Architecture & Multi-tenant
Schema-per-organization isolation with shared application logic. Every tenant gets their own data boundary; every release ships once, everywhere.
request → resolveTenant(host)
→ setSearchPath(tenant_xyz)
→ withRLS(user, building)
→ handler(...) ✓ scoped- Schema-per-org data isolation enforced at the connection layer
- Shared codebase — no per-customer forks, no drift to maintain
- Horizontal scale per tenant: hot buildings don't slow cold ones
- Tenant context carried through every query, job, and webhook
- Blue/green migrations roll forward without resident downtime
Identity & Access (ITIM)
Role-based access scoped to the tenant, the building, and the module. Every privileged action is logged with actor, target, and intent — so audits become a query, not a project.
can(user, 'invoice.void', {
tenant: 'acme',
building: 'tower-a',
module: 'pay',
}) → allow + log(actor, target)- Roles per tenant and per building — no global super-users
- Granular permissions per module surface, not per app
- Full audit trail of privileged actions with actor + reason
- Scoped service accounts for vendors, integrators, and bots
- SSO + MFA ready; session policies enforced server-side
Capabilities & Entitlements
Modules are capabilities, not bundles. Turn Pay on for one building, Lockers for another, RIO for the whole portfolio. Billing follows what's actually live.
tower-a → prime, pay, shield, lockers tower-b → prime, shield tower-c → prime, pay, rio (pilot) billing.sync() → reflects above
- Per-building module activation, toggled by admins not engineers
- Usage-based billing rails — invoices match what tenants used
- Capability checks at API, UI, and job layers — no leaks
- Trial windows, pilots, and rollbacks without code changes
- Cross-tenant data paths are structurally impossible
Schema Audit & Compliance
Continuous database governance built into the platform. Detect drift between environments, surface unsafe migrations before they ship, and keep a compliance trail your auditors can read.
✓ 142 tables — RLS enabled ✓ 318 policies — coverage verified ⚠ 2 columns — missing index in prod ✗ 1 migration — would block writes
- Live drift detection across dev, staging, and production
- Audit-ready migration history with author and approval chain
- RLS policy verification — every public table proven scoped
- Unsafe-migration guardrails: blocking locks, missing indexes
- Compliance exports (LGPD, GDPR) generated from the live schema
Theme & White-label
Each tenant brands their own surface. Boards, builders, and administradoras see their colors, their logo, their domain — without anyone forking a component or duplicating a screen.
host: portal.acme.com
→ tenant: acme
→ tokens: { brand, ink, canvas, ... }
→ applied: web + email + pdf + app- Per-tenant brand tokens — semantic, not hardcoded
- Custom domains per tenant with automatic TLS
- Theme isolation in dark and light, with no flash on load
- Logo, typography, and accent applied across every module
- Email, PDF, and resident app inherit the same brand system
Trust, inherited and enforced
NXHub inherits attestations from Cloudflare, Supabase, and AWS, then enforces tenant-level controls on top. Below is what's active today and what's on the roadmap.
See the full trust & compliance breakdownModules are easy. The platform is the moat.
If you're evaluating NXHub against single-purpose apps, this is what they don't have. Talk to us about your portfolio.