Per-client Easy!Appointments isolation #9

Closed
opened 2026-07-16 10:37:37 +02:00 by mivanchenko · 1 comment
Owner

Today booking runs a single shared Easy!Appointments instance (deploy/booking/). For real multi-client operation, isolate per client (separate EA instance/DB per client stack, mirroring the per-client nginx compose approach) so providers, services, and data don't bleed across clients.

Acceptance: two clients can be onboarded with fully separated booking data and admin logins.

Today booking runs a single shared Easy!Appointments instance (`deploy/booking/`). For real multi-client operation, isolate per client (separate EA instance/DB per client stack, mirroring the per-client nginx compose approach) so providers, services, and data don't bleed across clients. **Acceptance:** two clients can be onboarded with fully separated booking data and admin logins.
mivanchenko added the bookingenhancement labels 2026-07-16 10:37:37 +02:00
mivanchenko added the needs-triage label 2026-07-23 10:31:45 +02:00
Author
Owner

This was generated by AI during triage.

Superseded by the decision to build a single multi-tenant booking app with logical client_id isolation instead of per-client Docker stacks. Physical per-client isolation is kept only as a possible future paid exception (data-residency premium), not the default. Closing.

> *This was generated by AI during triage.* Superseded by the decision to build a single **multi-tenant** booking app with logical `client_id` isolation instead of per-client Docker stacks. Physical per-client isolation is kept only as a possible future *paid* exception (data-residency premium), not the default. Closing.
Sign in to join this conversation.