Multi-Tenant Architecture: Deploying Fooocus as a White-Label Solution for B2B Platforms

The Enterprise Demand for White-Label AI

The AI image generation market is experiencing a fundamental shift. What began as consumer-focused tools for creating artistic portraits has evolved into a mission-critical capability for enterprises across industries. Marketing teams need branded visual assets at scale. E-commerce platforms require product photography automation. Real estate companies demand virtual staging capabilities. And every one of these organizations wants the same thing: an AI image generation solution that reflects their brand, not yours.

This is the promise of white-label, multi-tenant AI platforms. By deploying Fooocus—the production-ready text-to-image system built on Stable Diffusion XL—as a multi-tenant service, you can offer enterprise customers their own branded image generation capabilities without building the underlying AI infrastructure from scratch.

But building a scalable, secure, and profitable multi-tenant AI platform presents unique challenges. How do you isolate customer data? How do you manage API rate limits across hundreds of tenants? How do you handle the asynchronous nature of AI generation without frustrating users? And how do you monetize effectively while maintaining performance?

This comprehensive guide addresses these questions and provides a practical roadmap for deploying Fooocus as a white-label, multi-tenant solution for B2B platforms. Drawing on real-world implementations and battle-tested architectural patterns, we’ll explore everything from infrastructure design to monetization strategies.

Part 1: Understanding Multi-Tenant Architectures for AI Systems

1.1 What Is Multi-Tenancy in the AI Context?

Multi-tenancy is an architectural pattern where a single instance of a software application serves multiple customers (tenants), with each tenant’s data isolated and invisible to others. For AI image generation platforms, this means:

• Tenant A’s generated images, prompts, and usage data are completely inaccessible to Tenant B
• Each tenant can have their own branding, API keys, and configuration settings
• Usage tracking and billing are segregated by tenant
• Performance SLAs can be customized per tenant

In the context of Fooocus deployments, multi-tenancy extends beyond traditional SaaS considerations. Each tenant may require:

• Custom model fine-tuning with their brand assets
• Style preservation for consistent brand identity across generated images
• Output validation to ensure compliance with brand guidelines
• Audit trails for compliance and regulatory requirements

1.2 The Business Case for White-Label Image Generation

Why would B2B platforms invest in white-label AI image generation? The market opportunity is substantial. As noted in industry analysis, “entrepreneurs are actively searching for business models where the initial investment is low but the upside is extremely high—AI art platforms fit this perfectly” .

Key Market Drivers:

Revenue Models That Work:

The most successful white-label AI platforms employ tiered monetization strategies. “A credit system, where users buy packages to generate images, upscale results, or unlock premium templates” has emerged as the dominant model . Subscription tiers offering unlimited generation or priority GPU access provide predictable recurring revenue, while commercial licensing options capture enterprise value.

1.3 Why Fooocus Is Ideal for Multi-Tenant Deployment

Fooocus offers several characteristics that make it particularly well-suited for white-label, multi-tenant deployments:

Production-Ready Defaults: Unlike base Stable Diffusion implementations requiring extensive parameter tuning, Fooocus delivers high-quality outputs with minimal configuration. This reduces the engineering overhead of maintaining tenant-specific quality standards.

Performance Flexibility: Four distinct speed presets—Extreme Speed, Lightning, Speed, and Quality—enable you to offer tiered service levels. Premium tenants can access the Quality preset for high-fidelity outputs, while free-tier users operate on Extreme Speed.

LoRA Support: The ability to load multiple LoRA models per request enables tenant-specific style preservation without model duplication. Each tenant can have their brand identity captured in a LoRA that loads automatically for their requests.

Style Layering: Fooocus’s intelligent style layering automatically applies enhancement styles without manual LoRA weight balancing, ensuring consistent quality across tenants.

Part 2: Reference Architectures for Multi-Tenant AI Platforms

2.1 The Hub-and-Spoke Pattern

For enterprises requiring strict data isolation and compliance, the hub-and-spoke architecture provides a robust foundation. This pattern, documented in AWS implementations for generative AI, uses a centralized hub account for shared services and dedicated spoke accounts for each tenant .

How It Works:

text

Hub Account (Shared Services)
├── Application Load Balancer (entry point)
├── Amazon Cognito (authentication)
├── Lambda Functions (tenant routing)
├── API Gateway (rate limiting, caching)
└── Transit Gateway (cross-account networking)
         ↓
    Transit Gateway Attachment
         ↓
Spoke Account (Tenant A)      Spoke Account (Tenant B)
├── Private VPC                ├── Private VPC
├── Amazon Bedrock endpoints   ├── Amazon Bedrock endpoints
├── IAM Roles                  ├── IAM Roles
└── Cost allocation tags       └── Cost allocation tags

Key Advantages:

• Complete isolation: Each tenant’s data and compute resources reside in separate AWS accounts
• Compliance readiness: Satisfies strict regulatory requirements for data segregation
• Cost visibility: Each tenant’s infrastructure costs are tracked independently
• Scalability: New tenants can be onboarded by provisioning additional spoke accounts

When to Use This Pattern:

This architecture is ideal for platforms serving enterprise customers with stringent security requirements—financial services, healthcare, or government agencies. “This multi-account approach helps maintain a well-architected system by providing better organization, security, and scalability” .

2.2 The Pooled Resource Pattern

For startups and platforms serving smaller customers, the pooled resource pattern offers a more cost-effective approach. Multiple tenants share the same infrastructure, with logical isolation through database partitioning and API key scoping.

How It Works:

text

Unified Infrastructure
├── Load Balancer
├── Fooocus API Service (shared)
├── Redis Queue (BullMQ)
├── PostgreSQL Database
│   ├── tenant_a schema
│   ├── tenant_b schema
│   └── tenant_c schema
├── MinIO/S3 Storage
│   ├── tenant-a/
│   ├── tenant-b/
│   └── tenant-c/
└── GPU Workers (pooled)

Key Advantages:

• Lower infrastructure costs: One GPU cluster serves all tenants
• Simplified management: Single deployment to maintain
• Faster onboarding: No infrastructure provisioning per tenant
• Easier development: Single codebase for all tenants

When to Use This Pattern:

This architecture works well for platforms targeting SMBs, agencies, and individual creators where absolute isolation is less critical than cost efficiency.

2.3 Real-World Implementation: Pollinations.ai

Pollinations.ai, a production AI generation platform, implements a sophisticated three-tier architecture that offers valuable lessons for multi-tenant deployments :

Tier 1: Client Layer
Multiple client types access the platform through a unified API: web frontend, React hooks, MCP server integration, and direct API calls. All requests flow through the same gateway regardless of client type, ensuring consistent authentication and rate limiting.

Tier 2: API Gateway
The gateway (implemented as a Cloudflare Worker) handles authentication, rate limiting, balance checks, and caching. Key components include:

• Per-key rate limiting via Durable Objects
• Balance verification against user accounts before processing
• Request deduplication for identical concurrent requests
• R2 bucket caching for generated content

Tier 3: Backend Services
Separate services handle text and image generation, each routing to multiple provider APIs. The image service integrates with various providers (OpenAI, Google Gemini, Stability AI) and includes:

• Fallback logic for provider failures
• Load balancing across multiple endpoints
• Cost tracking per request

Critical Design Pattern: Two-Phase Event Tracking

One of Pollinations’ most important innovations for multi-tenant billing is two-phase event tracking:

1. Estimate events: Created before proxying requests to calculate pending spend
2. Pending events: Created after response with actual usage

This prevents race conditions where balance checks might miss in-flight requests. The available balance calculation becomes:

text

Available Balance = tierBalance + packBalance - pendingSpend

For multi-tenant platforms with usage-based billing, this pattern is essential to prevent users from exceeding their limits during the event processing window.

2.4 Real-World Implementation: OurDream AI Clone

The OurDream AI clone platform demonstrates how white-label AI generators achieve commercial success . The architecture includes:

• Model engine: SDXL or Flux-based architectures for crisp detail and accurate reconstruction
• Cached processes: Compute batching and optimized GPU routing for speed
• Face-preserving tools: Character consistency across multiple generations
• Private cloud storage: Options for users who need data isolation

Technology Stack:

• Next.js or React for user interface
• Python-based APIs for image generation pipelines
• GPU-backed inference servers using CUDA/TensorRT
• Redis and PostgreSQL for session management, usage logs, and caching
• AWS or GCP for dynamic scaling

Part 3: Implementing Tenant Isolation for Fooocus

3.1 Storage Isolation Strategies

Image storage is a critical isolation boundary. Three primary approaches exist:

Strategy 1: Separate Buckets/Directories

The simplest approach uses separate storage paths per tenant. As documented in GLM-Image multi-user configurations, you can modify the output logic to create tenant-specific directories :

python

def save_image_with_tenant(image, tenant_id: str):
    # Create tenant-specific directory
    tenant_output_dir = os.path.join(args.output_base, tenant_id)
    os.makedirs(tenant_output_dir, exist_ok=True)
    
    # Generate filename with timestamp
    timestamp = datetime.now().strftime("%Y%m%d_%H%M%S")
    filename = f"{timestamp}.png"
    filepath = os.path.join(tenant_output_dir, filename)
    
    image.save(filepath)
    return filepath

For cloud storage, use bucket prefixes:

text

s3://image-platform/
├── tenant-123/
│   ├── images/
│   └── prompts/
├── tenant-456/
│   ├── images/
│   └── prompts/

Strategy 2: Separate Buckets per Tenant

For enterprise customers requiring strict data segregation, provision dedicated storage buckets per tenant. This satisfies compliance requirements and enables tenant-managed encryption keys.

Strategy 3: Signed URLs with Tenant Context

For API access, generate signed URLs that encode tenant context. All requests validate tenant identity before granting access.

3.2 Prompt and Output Isolation

The non-deterministic nature of AI generation requires careful attention to data isolation:

Log Segregation

• Store prompts and generation parameters in tenant-specific database tables
• Implement row-level security to prevent cross-tenant access
• Log all generation events with tenant context for audit purposes

Output Validation

• Validate that generated images don’t contain cross-tenant information
• Implement content filtering per tenant (some tenants may allow NSFW, others prohibit it)
• Support tenant-specific brand guidelines through custom LoRAs

3.3 API Key Management for Multi-Tenancy

For platforms offering API access, proper key management is essential:

python

# API key structure with tenant context
class TenantAPIKey:
    key_id: str
    tenant_id: str
    permissions: List[str]  # ['generate', 'upscale', 'vary']
    rate_limit_rpm: int
    rate_limit_tpm: int
    created_at: datetime
    expires_at: Optional[datetime]

Best Practices:

• Store keys hashed in database (never plaintext)
• Implement per-tenant rate limiting separate from per-key limits
• Rotate keys regularly with automated expiration
• Log all API usage with tenant and key context

3.4 Configuration per Tenant

Different tenants have different needs. A flexible configuration system enables:

yaml

# Tenant configuration example
tenant_123:
  default_model: "fooocus-v2"
  default_performance: "Quality"
  allowed_styles:
    - "Fooocus Enhance"
    - "Fooocus Sharp"
    - "Fooocus V2"
  custom_loras:
    - "brand-assets-v3"
    - "product-photography-v1"
  content_filtering:
    nsfw_threshold: 0.9
    banned_categories: ["violence", "hate"]
  storage:
    bucket: "tenant-123-assets"
    encryption: "customer-managed"

This configuration can be stored in a database and loaded during request processing, enabling tenant-specific behavior without code changes.

Part 4: Production-Ready API Design Patterns

4.1 The Queue-Based Architecture

AI image generation is fundamentally asynchronous. The naive approach—blocking until generation completes—fails in production. As one engineering team discovered, “in development, everything worked. In production with real users hitting the generate button, everything broke” .

The Problem with Synchronous APIs:

python

# This will fail in production
@router.post("/generate")
async def generate_image(prompt: str):
    # This blocks for 15-60 seconds
    result = await fooocus.generate(prompt)
    return result  # User waits, connection may timeout

This approach has multiple production-killing problems:

• Request timeout (load balancers kill connections after 30s)
• No retry logic for transient failures
• Memory pressure from pending requests
• No rate limit awareness
• Poor observability

The Solution: Queue-Based Architecture

python

# Production-ready async API
@router.post("/generate")
async def generate_image(prompt: str, tenant_id: str):
    job = await queue.add("generate-image", {
        "tenant_id": tenant_id,
        "prompt": prompt,
        "created_at": datetime.utcnow()
    }, {
        "attempts": 3,
        "backoff": {"type": "exponential", "delay": 5000},
        "priority": get_tenant_priority(tenant_id)
    })
    
    return {
        "job_id": job.id,
        "status": "queued",
        "estimated_wait_seconds": await estimate_wait_time()
    }

Key Benefits:

• Immediate response: Users get a job ID in <100ms
• Built-in retries: Exponential backoff handles transient failures
• Backpressure control: Concurrency limits prevent overload
• Priority support: Premium tenants can jump the queue
• Observability: Queue depth, processing time, failure rates tracked

4.2 The Worker Pattern with Concurrency Control

The worker component processes jobs from the queue with careful concurrency management:

python

from bullmq import Worker
from circuit_breaker import CircuitBreaker

class ImageGenerationWorker:
    def __init__(self):
        self.breaker = CircuitBreaker(
            self.call_fooocus,
            {
                "timeout": 90000,  # 90 seconds
                "error_threshold_percentage": 50,
                "reset_timeout": 30000
            }
        )
    
    async def process(self, job):
        await job.update_progress(10)
        
        # Apply tenant-specific prompt engineering
        prompt = self.build_prompt_with_tenant_style(
            job.data["prompt"], 
            job.data["tenant_id"]
        )
        
        await job.update_progress(20)
        
        try:
            # Circuit breaker protects against API outages
            result = await self.breaker.call(prompt)
            
            await job.update_progress(80)
            
            # Store in tenant-specific location
            url = await self.storage.upload(
                result.image, 
                tenant_id=job.data["tenant_id"]
            )
            
            await self.notify_tenant(job.data["tenant_id"], {
                "job_id": job.id,
                "status": "completed",
                "image_url": url
            })
            
            return {"image_url": url}
            
        except Exception as e:
            if self.is_retryable(e):
                # Let BullMQ retry with backoff
                raise e
            else:
                # Permanent failure - don't retry
                await self.notify_tenant(
                    job.data["tenant_id"], 
                    {"status": "failed", "error": str(e)}
                )
                raise UnrecoverableError(str(e))

Critical Configuration:

• Concurrency: Limit simultaneous generations to prevent GPU OOM
• Rate limiter: Cap jobs per minute to stay within API quotas
• Circuit breaker: Open circuit when failure rate exceeds threshold

4.3 Real-Time Status Updates

Users need visibility into generation progress. Server-Sent Events (SSE) provide efficient real-time updates:

python

@router.get("/status/{job_id}")
async def stream_status(job_id: str):
    async def event_generator():
        while True:
            job = await queue.get_job(job_id)
            if not job:
                break
                
            state = await job.get_state()
            progress = job.progress
            
            yield {
                "event": "status",
                "data": {
                    "state": state,
                    "progress": progress
                }
            }
            
            if state in ["completed", "failed"]:
                break
                
            await asyncio.sleep(2)  # Poll every 2 seconds
    
    return EventSourceResponse(event_generator())

Why This Matters:
Research shows that “users tolerate 45-second waits when they see a progress bar. They abandon after 10 seconds of a blank spinner” .

4.4 Circuit Breaker for API Resilience

When integrating with external AI services (or even self-hosted Fooocus instances), failures are inevitable. A circuit breaker prevents cascading failures:

python

from circuit_breaker import CircuitBreaker, CircuitOpenError

class ResilientFooocusClient:
    def __init__(self):
        self.breaker = CircuitBreaker(
            self._call_fooocus_api,
            {
                "timeout": 90000,           # 90 seconds
                "error_threshold": 50,       # 50% failure rate
                "reset_timeout": 30000,      # 30 seconds
                "volume_threshold": 5        # Minimum 5 requests
            }
        )
        
        self.breaker.on_open = lambda: self.logger.warning("Circuit OPEN")
        self.breaker.on_close = lambda: self.logger.info("Circuit CLOSED")
    
    async def generate(self, prompt: str):
        try:
            return await self.breaker.call(prompt)
        except CircuitOpenError:
            # Queue jobs while circuit is open
            raise ServiceUnavailable("Image generation temporarily unavailable")

4.5 Rate Limiting per Tenant

Multi-tenant platforms must enforce rate limits per tenant to prevent abuse:

python

from redis import Redis

class TenantRateLimiter:
    def __init__(self, redis_client: Redis):
        self.redis = redis_client
    
    async def check_limit(self, tenant_id: str, limit_rpm: int):
        key = f"ratelimit:{tenant_id}:minute"
        current = await self.redis.incr(key)
        
        if current == 1:
            await self.redis.expire(key, 60)
        
        if current > limit_rpm:
            raise RateLimitExceeded(f"Tenant {tenant_id} exceeded {limit_rpm} RPM")
        
        return current

For more sophisticated needs, implement:

• Token bucket algorithm for burst allowance
• Sliding window counters for precise limits
• Per-endpoint limits (generate vs. upscale vs. vary)
• Tier-based limits (free: 10/min, pro: 100/min, enterprise: unlimited)

Part 5: White-Label Customization Strategies

5.1 Custom Model Fine-Tuning

The most valuable white-label feature is the ability to fine-tune models with tenant-specific assets:

Use Cases:

• Brand style preservation: Train a LoRA on tenant’s marketing materials
• Product photography: Fine-tune on tenant’s product catalog
• Character consistency: Maintain same face across generations for game assets

Implementation:

python

class TenantModelManager:
    def __init__(self):
        self.model_registry = {}  # tenant_id -> LoRA path
    
    def register_tenant_lora(self, tenant_id: str, lora_path: str):
        self.model_registry[tenant_id] = lora_path
    
    async def generate_with_tenant_model(self, tenant_id: str, prompt: str):
        lora_path = self.model_registry.get(tenant_id)
        
        if lora_path:
            # Load tenant-specific LoRA
            return await fooocus.generate(
                prompt=prompt,
                loras=[{
                    "path": lora_path,
                    "weight": 0.8
                }]
            )
        else:
            return await fooocus.generate(prompt=prompt)

5.2 Style Presets and Templates

Different tenants have different aesthetic requirements. Provide configurable style presets:

yaml

tenant_style_configs:
  ecommerce_tenant:
    default_styles:
      - "Fooocus Enhance"
      - "Product Photography"
    negative_prompts:
      - "blurry"
      - "watermark"
      - "text"
    aspect_ratios:
      - "1:1"
      - "4:3"
      - "16:9"
  
  gaming_tenant:
    default_styles:
      - "Fantasy Art"
      - "Concept Art"
    negative_prompts:
      - "modern"
      - "realistic"
    aspect_ratios:
      - "16:9"
      - "21:9"

5.3 Branded Outputs

White-label platforms must deliver images that align with tenant branding:

• Watermarking: Add tenant’s logo or watermark to generated images
• Color grading: Apply brand color palettes to outputs
• Output formats: Configure JPEG quality, PNG transparency, or WebP compression
• Metadata: Embed tenant information in image EXIF data

5.4 Custom Domains and SSL

For true white-label experiences, tenants should access the platform through their own domains:

text

https://ai-generator.tenant-a.com → Your Platform
https://magic-images.tenant-b.com → Your Platform

Implementation considerations:

• SNI-based routing for SSL certificates
• Let’s Encrypt automation for certificate provisioning
• DNS management for tenant domains
• CORS configuration for cross-origin requests

Part 6: Billing and Usage Tracking

6.1 Credit-Based Billing Systems

The most common monetization model for AI image platforms is credit-based billing. Users purchase credits, and each generation consumes credits based on:

• Model complexity: Quality preset consumes more credits than Speed
• Output resolution: Higher resolutions cost more
• Upscaling: Additional operations consume extra credits
• LoRA usage: Custom models may incur premium pricing

Credit Consumption Matrix Example:

6.2 Usage Tracking Architecture

Accurate usage tracking requires careful design to prevent loss:

python

class UsageTracker:
    async def track_generation(self, tenant_id: str, job_id: str, usage: Usage):
        # Create pending record
        await db.execute("""
            INSERT INTO usage_records 
            (tenant_id, job_id, status, credits, created_at)
            VALUES ($1, $2, 'pending', $3, NOW())
        """, tenant_id, job_id, usage.credits)
        
        # Update pending spend cache for rate limiting
        await redis.incrby(
            f"tenant:{tenant_id}:pending_spend", 
            usage.credits
        )
        
        # Schedule confirmation
        await scheduler.schedule(
            delay=3600,  # 1 hour
            callback=self.confirm_usage,
            args=(job_id,)
        )
    
    async def confirm_usage(self, job_id: str):
        # Check if generation completed successfully
        status = await self.get_job_status(job_id)
        
        if status == "completed":
            await db.execute("""
                UPDATE usage_records 
                SET status = 'confirmed', confirmed_at = NOW()
                WHERE job_id = $1
            """, job_id)
        else:
            # Refund credits for failed generations
            await db.execute("""
                UPDATE usage_records 
                SET status = 'refunded', refunded_at = NOW()
                WHERE job_id = $1
            """, job_id)

6.3 Subscription Tiers with Usage Limits

Many platforms combine subscriptions with usage-based overage:

Tiered Subscription Model:

6.4 Preventing Balance Exhaustion

Critical pattern from Pollinations: prevent users from exceeding balances by tracking pending spend :

python

async def check_balance(tenant_id: str):
    # Get settled balance
    balance = await db.get_balance(tenant_id)
    
    # Get pending spend from in-flight jobs
    pending = await redis.get(f"tenant:{tenant_id}:pending_spend") or 0
    
    # Available = balance - pending
    available = balance - pending
    
    if available <= 0:
        raise InsufficientBalance(
            f"Available balance {available} (balance {balance} - pending {pending})"
        )
    
    return available

This prevents users from exceeding their limits during the window between generation start and billing confirmation.

Part 7: Deployment and Scaling Strategies

7.1 GPU Infrastructure for Multi-Tenant Workloads

For self-hosted Fooocus deployments, GPU infrastructure planning is critical:

Scaling Options:

Auto-Scaling Configuration:

yaml

scaling_rules:
  - metric: queue_depth
    threshold: 10
    action: add_worker
    cooldown: 60s
  
  - metric: queue_depth
    threshold: 0
    action: remove_worker
    cooldown: 300s
  
  - metric: gpu_memory_usage
    threshold: 85%
    action: drain_worker
    cooldown: 30s

7.2 Multi-Region Deployment

For global platforms, multi-region deployment reduces latency:

text

User in APAC → Singapore region → Fooocus GPU cluster
User in EU    → Frankfurt region → Fooocus GPU cluster
User in US    → Oregon region   → Fooocus GPU cluster

Data Consistency:

• Use global database with read replicas per region
• Implement region-aware routing based on user location
• Store generated images in region-specific buckets
• Replicate metadata globally, images regionally

7.3 Cost Optimization Strategies

GPU costs dominate AI platform expenses. Optimize with:

Batching: Combine multiple generation requests into batches where possible

Caching: Cache identical prompt+seed combinations to avoid redundant generation

Model Quantization: Use INT8 or FP16 models to reduce memory footprint

Idle Timeout: Scale down workers during low-traffic periods

Reserved Instances: Purchase reserved GPU instances for predictable workloads

Part 8: Security and Compliance

8.1 Data Privacy for Multi-Tenant AI

Enterprise customers will scrutinize your data handling practices:

Key Requirements:

• No training on customer data without explicit consent
• Clear data retention and deletion policies
• Audit logs of all data access
• Encryption at rest and in transit
• SOC 2 Type II compliance (discussed in previous article)

8.2 Prompt Injection Prevention

AI systems are vulnerable to prompt injection attacks where users attempt to bypass safety filters:

python

class PromptSafetyFilter:
    def __init__(self):
        self.banned_patterns = [
            r"ignore previous instructions",
            r"you are now .* mode",
            r"pretend you are",
            r"disregard safety",
            r"no restrictions"
        ]
        
        self.banned_categories = [
            "nsfw", "violence", "hate_speech", "harassment"
        ]
    
    def validate_prompt(self, prompt: str, tenant_config: dict) -> bool:
        # Check for injection patterns
        for pattern in self.banned_patterns:
            if re.search(pattern, prompt, re.IGNORECASE):
                raise PromptInjectionDetected(f"Suspicious pattern: {pattern}")
        
        # Check content safety (using tenant thresholds)
        safety_score = self.check_safety(prompt)
        threshold = tenant_config.get("nsfw_threshold", 0.8)
        
        if safety_score > threshold:
            raise UnsafeContentDetected(f"Safety score {safety_score} exceeds threshold")
        
        return True

8.3 Tenant Data Isolation Verification

Regular testing should verify that tenant data isolation works:

python

def test_tenant_isolation():
    # As Tenant A
    result_a = api.generate(prompt="test", tenant="A")
    image_a_url = result_a.image_url
    
    # As Tenant B (malicious attempt to access Tenant A's image)
    with pytest.raises(Unauthorized):
        api.get_image(image_a_url, tenant="B")
    
    # Verify database isolation
    db_a = get_tenant_db("A")
    db_b = get_tenant_db("B")
    
    assert db_a.query("SELECT COUNT(*) FROM images") > 0
    assert db_b.query("SELECT COUNT(*) FROM images") == 0

Conclusion: The Multi-Tenant Opportunity

Deploying Fooocus as a white-label, multi-tenant solution represents a significant business opportunity. The market for AI image generation continues to expand, with enterprises across industries seeking to integrate these capabilities into their workflows.

Success requires careful attention to architecture. The patterns outlined in this guide—from hub-and-spoke isolation to queue-based processing to tenant-specific model fine-tuning—provide a roadmap for building platforms that are secure, scalable, and profitable.

Key Takeaways:

1. Start with isolation strategy: Decide between dedicated infrastructure per tenant or pooled resources based on your target market
2. Embrace asynchronous patterns: AI generation requires queue-based architectures with proper retry logic and circuit breakers
3. Design for white-label flexibility: Enable tenant-specific branding, models, and configurations from day one
4. Build robust billing: Implement credit systems with pending spend tracking to prevent balance exhaustion
5. Plan for scale: Auto-scaling GPU infrastructure and multi-region deployment prepare you for growth

The platforms that succeed in this space won’t simply offer AI image generation—they’ll offer enterprise-ready solutions that integrate seamlessly into customers’ existing workflows while maintaining the security, reliability, and performance that businesses demand.

With Fooocus as your foundation and the architectural patterns outlined in this guide, you’re well-positioned to build the next generation of white-label AI image generation platforms.