~/wiki
Récent+ Ajouter

per client deployment pattern

---
title: Per-Client Deployment Pattern  
category: concepts
created: 2026-12-21
updated: 2025-01-04
tags: [deployment-architecture, client-isolation, saas-scaling, workspace-sandboxing, multi-tenant-security, openclaw, docker-containers, telegram-bots, claude-api, security-patterns, resource-management, gcp-deployment, shared-vm-infrastructure, container-orchestration, instance-isolation, cross-client-prevention, docker-compose, dedicated-resources, linear-scaling, cost-optimization, per-client-billing, infrastructure-efficiency, maintenance-separation]
sources: [raw/conversations/2026-03-27-cursor-openclaws-6ddf77d1.md]
confidence: high
---

# Per-Client Deployment Pattern

Architectural approach for client-facing AI services where each client receives their own isolated deployment instance rather than sharing a multi-tenant system. Particularly relevant for [client-facing-ai-development](/concepts/client-facing-ai-development) scenarios requiring strict workspace isolation and security boundaries.

## Core Architecture

### Individual Instance Strategy
Instead of building a single multi-tenant application, deploy separate containerized instances per client:

- **Dedicated containers**: Each client gets their own Docker container
- **Isolated workspaces**: Complete separation of file systems and processes
- **Independent resources**: CPU, memory, and storage allocation per instance
- **Separate configurations**: Client-specific settings without shared state

### Security Advantages

#### Complete Isolation
- **Process separation**: Client workloads cannot access each other's memory or CPU
- **Filesystem isolation**: Impossible for one client to access another's files
- **Network separation**: Container-level networking prevents cross-client communication
- **Configuration isolation**: No shared configuration that could leak between clients

#### Reduced Attack Surface
- **Limited blast radius**: Security breach affects only single client
- **No privilege escalation**: Cannot move laterally between client environments
- **Simplified auditing**: Clear boundaries for security monitoring
- **Incident containment**: Problems isolated to specific client instance

### Implementation in Shared VM Infrastructure

#### Docker Orchestration
For openclaw deployment on shared GCP VM:

```yaml
# docker-compose.client1.yml
version: '3.8'
services:
  openclaw-client1:
    image: openclaw:latest
    environment:
      - WORKSPACE_PATH=/workspaces/client1
      - TELEGRAM_BOT_TOKEN=${CLIENT1_BOT_TOKEN}
      - CLAUDE_API_KEY=${CLAUDE_API_KEY}
    volumes:
      - ./clients/client1:/workspaces/client1
    networks:
      - client1-network

Directory Structure

/var/www/
├── clients/
│   ├── client1/           # Isolated workspace
│   │   ├── website/
│   │   └── configs/
│   ├── client2/           # Separate isolation
│   │   ├── website/
│   │   └── configs/
│   └── client3/
├── openclaw-instances/
│   ├── client1-compose.yml
│   ├── client2-compose.yml
│   └── client3-compose.yml

Resource Management

Scaling Characteristics

  • Linear resource growth: Each client adds predictable resource requirements
  • Granular monitoring: Per-client resource usage tracking
  • Independent scaling: Scale individual client instances based on usage
  • Cost attribution: Direct cost allocation per client

Resource Allocation Strategies

Memory Limits:

deploy:
  resources:
    limits:
      memory: 512M
    reservations:
      memory: 256M

CPU Constraints:

deploy:
  resources:
    limits:
      cpus: '0.5'
    reservations:  
      cpus: '0.25'

Operational Benefits

Simplified Maintenance

  • Independent updates: Update client instances without affecting others
  • Isolated testing: Test changes on single client before broader rollout
  • Rollback granularity: Revert specific client without system-wide impact
  • Debug isolation: Troubleshoot issues within clearly defined boundaries

Client-Specific Customization

  • Custom configurations: Tailor instance settings per client requirements
  • Version flexibility: Run different software versions for different clients
  • Feature flags: Enable/disable features per client instance
  • Performance tuning: Optimize individual instances for specific workloads

Business Model Alignment

Cost Structure

  • Transparent billing: Direct correlation between client usage and infrastructure cost
  • Scalable pricing: Charge based on actual resource consumption
  • Cost optimization: Identify and optimize expensive client workloads
  • Resource planning: Predict infrastructure needs based on client growth

Service Level Management

  • Individual SLAs: Set different service levels per client tier
  • Performance isolation: High-priority clients unaffected by others
  • Resource guarantees: Dedicated resources ensure consistent performance
  • Monitoring granularity: Per-client uptime and performance metrics

Comparison with Multi-Tenant Patterns

Multi-Tenant Disadvantages

  • Shared failure modes: Single bug affects all clients
  • Security complexity: Complex permission systems prone to vulnerabilities
  • Resource contention: Clients compete for shared resources
  • Deployment coupling: Updates must be tested across all client scenarios

Per-Client Advantages

  • Simplified security model: Container-level isolation is well-understood
  • Independent deployments: Each client can have different deployment schedules
  • Clear resource boundaries: No "noisy neighbor" problems
  • Easier compliance: Simpler to meet client-specific regulatory requirements

Implementation Considerations

Automation Requirements

  • Instance provisioning: Automated Docker container deployment
  • Configuration management: Template-based client setup
  • Monitoring deployment: Per-instance observability configuration
  • Backup orchestration: Individual backup schedules per client

Management Overhead

  • Instance lifecycle: Create, update, and destroy client instances
  • Configuration drift: Ensure consistency across similar client setups
  • Resource monitoring: Track usage patterns across all instances
  • Update coordination: Manage updates across multiple independent instances

Infrastructure Planning

  • Capacity planning: Estimate resource growth with client additions
  • Load distribution: Balance instances across available infrastructure
  • Network planning: IP allocation and port management per instance
  • Storage planning: Disk space allocation and backup storage requirements

Use Cases

Ideal Scenarios

  • client-facing-ai-development: Direct client access requiring strict isolation
  • Regulated environments: Compliance requirements mandate client separation
  • Custom integrations: Each client needs specific third-party connections
  • Variable workloads: Clients with significantly different usage patterns

Anti-Patterns

  • Homogeneous clients: All clients have identical requirements and usage
  • High client density: Hundreds of small clients on limited infrastructure
  • Frequent cross-client operations: Business logic requires client data sharing
  • Cost-sensitive scenarios: Infrastructure costs outweigh isolation benefits

Success Metrics

Security Effectiveness

  • Incident isolation: Percentage of security issues contained to single client
  • Cross-client vulnerabilities: Zero incidents of client data leakage
  • Audit simplicity: Time reduction in security compliance reviews

Operational Efficiency

  • Deployment independence: Percentage of deployments affecting single client
  • Troubleshooting time: Average time to isolate and resolve client issues
  • Resource utilization: Efficiency of resource allocation per client

Business Impact

  • Client satisfaction: Improved due to performance isolation
  • Sales enablement: Security isolation as competitive differentiator
  • Cost transparency: Clear client cost attribution for pricing optimization

See also