Skip to main content

Multi-Account Deployment

This guide covers managing multiple white-label client deployments from a single codebase.

Overview​

The LAS platform supports multiple clients (accounts) with:

  • Separate databases per client
  • Individual branding and configuration
  • Isolated user bases
  • Shared codebase for easier maintenance

Architecture​

┌─────────────────────────────────────────────────────────────┐
│                    Shared Codebase                          │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│   Client A              Client B              Client C      │
│   ┌─────────┐          ┌─────────┐          ┌─────────┐    │
│   │ Config  │          │ Config  │          │ Config  │    │
│   │ Branding│          │ Branding│          │ Branding│    │
│   │ Database│          │ Database│          │ Database│    │
│   └─────────┘          └─────────┘          └─────────┘    │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Client Structure​

Each client has a dedicated folder:

clients/
├── client-a/
│   ├── config.json       # Client configuration
│   ├── assets/           # Logos, icons
│   └── supabase-env.txt  # Database credentials
├── client-b/
│   └── ...
└── client-c/
    └── ...

Configuration​

Client Config File​

Each client has a config.json with:

{
  "branding": {
    "appName": "Client App",
    "organizationName": "Client Org"
  },
  "theme": {
    "primaryColor": "#4F46E5"
  },
  "features": {
    "community": true,
    "appointments": true
  }
}

Assets​

Each client needs:

  • Logo files (512x512, 192x192)
  • Favicon
  • Any custom images

Deployment​

Single Client Deployment​

./scripts/deploy-client.sh client-name production

All Clients Deployment​

./scripts/deploy-all-clients.sh production

Database Isolation​

Each client has:

  • Separate Supabase project
  • Own database with full data isolation
  • Individual RLS policies
  • Separate auth users

Updates​

When updating the shared codebase:

  1. Test changes locally
  2. Deploy to staging
  3. Test with each client configuration
  4. Deploy to production for all clients

Best Practices​

Security​

  • Never share credentials between clients
  • Use separate API keys per client
  • Rotate credentials regularly

Maintenance​

  • Keep client configurations in version control
  • Document any client-specific customizations
  • Regular backups for each client database

Updates​

  • Test updates with all client configurations
  • Coordinate deployment timing with clients
  • Have rollback procedures ready