Tenancy Architecture

Every customer receives their own dedicated database instance — your data is physically separate from every other customer, not just logically partitioned within a shared database. On top of that, the platform enforces six layers of isolation: dedicated connection strings per tenant, scoped pipeline context, EF Core global query filters as a safety net, JWT-based tenant claim validation on every request, automated integration tests that verify cross-tenant data cannot leak, and runtime monitoring that alerts on any tenant context mismatch. In today’s single-tenant deployment, each customer also runs in separate application containers, making cross-tenant access physically impossible. Learn more about the defense-in-depth isolation model and our data handling practices.

You stay in full control of your update timeline. In the current single-tenant model, updates are deployed to each customer independently — your environment can be on a different version than any other customer, and deployments can be scheduled around your business calendar, peak seasons, or internal change-management windows. In a multi-tenant deployment, the application is updated once for all tenants, but feature flags provide granular control so new capabilities can be enabled or disabled per customer. Either way, you’re never surprised by unexpected changes. See the full update & rollback strategy.

Absolutely. In a single-tenant deployment, your environment is pinned to a specific version — other customers can move forward while yours stays frozen for as long as needed. When you’re ready, the update is applied and any pending database migrations run automatically. In a multi-tenant deployment, feature flags keep new behavior disabled for your tenant while others receive it. For critical regulatory freezes (like quarter-close or audit periods), a tenant can even be temporarily promoted to a dedicated single-tenant instance for complete version control. See the update & rollback strategy for details.

Today’s infrastructure provisioning is fully automated and completes in approximately 5 minutes — that includes creating the Kubernetes namespace, database, application containers, SSL certificate, and DNS entry. From there, business configuration (connecting your ERP, setting up payment providers, and configuring site settings) typically takes 30–60 minutes in collaboration with your team. As the platform evolves toward multi-tenancy, infrastructure provisioning drops to roughly 30 seconds since only a new database and tenant registry entry are needed. The long-term vision includes a self-service tenant admin portal for near-instant provisioning. See the full onboarding walkthrough.

Clarity uses a three-layer customization model that keeps the core platform unified. Layer 1 — Configuration handles over 80% of customization needs through settings, feature toggles, and branding — no code required. Layer 2 — Pipeline Hooks lets you inject custom logic at any point in a business workflow (before payment capture, after order sync, etc.) without modifying the core engine. Layer 3 — Client Plugin provides a dedicated code project for truly unique requirements like custom entities, service overrides, or additional API endpoints. All three layers are additive and isolated, so core platform updates apply cleanly without breaking any customizations. Learn more about customization layers and pipeline hooks.

We recommend a hybrid model that matches the right deployment tier to each customer’s needs. Enterprise customers with complex customizations, strict compliance requirements, or regulatory obligations receive dedicated single-tenant instances with full version control and isolation. Standard mid-market customers benefit from efficient multi-tenant deployment with database-per-tenant isolation — delivering faster provisioning and lower overhead while maintaining strong data separation. The same platform, codebase, and engineering team serves both tiers seamlessly, with no forks and no divergence. Explore the hybrid tier model for the full breakdown.

Performance isolation is built into every layer. At the database level, each tenant has their own dedicated database instance, so a large data sync or heavy reporting query from one customer never touches another’s resources. At the application tier, per-tenant rate limiting, concurrency caps on ERP connector sync operations, background task quotas, and Kubernetes horizontal pod autoscaling ensure that no single tenant can monopolize shared compute resources. Enterprise customers on dedicated instances have zero noisy-neighbor risk by design. The result: consistent, predictable performance for every customer regardless of what others are doing on the platform.

All connector credentials — ERP API keys, payment gateway tokens, OAuth secrets — are stored exclusively in each customer’s own dedicated database within encrypted Settings entities. There is no shared or centralized credential store. When the platform needs to authenticate to your ERP or payment provider, it resolves the tenant-scoped database context, reads your credentials from your database only, and establishes the connection. Credentials never appear in Docker images, source control, environment variables, or any shared configuration. This means even in a multi-tenant deployment, one customer’s credentials are physically inaccessible to another customer’s application context.

Each customer’s database has independent backup schedules with point-in-time recovery — typically a 15-minute RPO (Recovery Point Objective) using cloud-managed database services. The application tier is fully stateless, which means it recovers instantly via Kubernetes pod rescheduling with no data loss. Redis cache is ephemeral by design — if lost, it causes a brief performance dip while the cache warms, but no business data is affected. In multi-tenant deployments, the tenant registry (the routing layer that maps requests to databases) is the highest-priority component and is replicated with the strongest durability guarantees. For organizations requiring geographic redundancy, cross-region disaster recovery is supported through cloud-managed database replication and multi-region Kubernetes deployment.

Yes — full white-labeling is built into the platform. The theme editor in the Remix frontend allows per-tenant customization of colors, fonts, logos, and layout through Tailwind CSS variables stored in the database. Embedded payment forms automatically inherit the tenant’s theme so they feel native within ERP interfaces. Email notifications and customer-facing communications use per-tenant Handlebars templates with your branding. The result is a seamless chain: your team sees your brand in the admin portal, and your end-customers see your brand on payment pages, invoices, and email receipts — with no trace of the underlying platform.