Organization tenancy
Organization is the root tenant
Every tenant-owned resource includes an immutable organization_id.
Examples:
applications
environments
source_repositories
builds
deployments
database_instances
kv_namespaces
secrets
ip_lists
access_policies
identity_providers
audit_events
usage_records
A user may belong to multiple organizations and explicitly switch the active tenant in Filament.
Filament provides tenant-oriented UI and routing primitives, but its documentation makes clear that tenancy is security-sensitive and that application developers remain responsible for correctly enforcing it. Its canAccessTenant() check is specifically necessary to prevent a user from guessing another tenant’s identifier. Filament tenancy
Filament tenancy is therefore a UI and routing convenience—not the sole security boundary.
Defense-in-depth tenancy controls
Use all of the following:
- Explicit
TenantContextpassed to application services. - Laravel policies for every resource.
- Mandatory organization filtering in repositories/query objects.
- PostgreSQL row-level security for tenant-owned tables.
- Composite unique constraints containing
organization_id. - Queue jobs containing and revalidating tenant context.
- Object-storage keys prefixed by opaque organization/application IDs.
- Runtime cluster commands scoped to an organization and cluster.
- Cross-tenant integration tests and property tests.
- Separate administrative database role for migrations and maintenance.
For PostgreSQL RLS, each web/job transaction should set a local organization context. Normal application database roles must not bypass RLS.
Identifier strategy
Use ULIDs or UUIDv7 internally.
Human-readable slugs are routing/display values, not authorization boundaries.
org_01K...
app_01K...
env_01K...
dep_01K...
An organization app may display:
Example Organization / Equipment Requests
while its underlying repository, object-storage prefix, and database binding use immutable IDs.