Servicio is a multi-tenant SaaS. Multiple shops share the same infrastructure and database, but each shop's data is completely isolated from every other shop. This isolation is not a policy — it is the query layer.
The model
- Every tenant-scoped table (clients, visits, invoices, etc.) has a
tenant_idcolumn. - A global Eloquent scope filters every query by the current tenant automatically.
- The current tenant is resolved from middleware early in every request.
- Queries that try to bypass the scope are rejected.
- Route-bound models (e.g., a specific visit ID in a URL) are checked against the current tenant before the controller sees them.
What this means for you
- Your data cannot accidentally leak to another tenant.
- Your data cannot be queried by another tenant, even by Servicio staff without explicit super-admin impersonation (which is audit-logged).
- When you delete your tenant, your data is soft-deleted first then hard-deleted after 30 days. No residual copies.
Our super-admin role exists for Servicio's own support team. When support impersonates your tenant to help with an issue, an audit log row is written on your side with the staff member's name. You can always see who has been in your account and when.
Tenant isolation and integrations
When Servicio calls external services on your behalf (Stripe, Twilio, Postmark), the credentials and callbacks are tenant-scoped. A Stripe webhook that arrives from another tenant's Stripe account is rejected by the webhook router. Credentials (API keys, OAuth tokens) are encrypted at rest, per-tenant.