Skip to content

Domain Structure

The Orchestra Platform is organized around a clear, hierarchical domain structure that separates different platform functions and provides unique access points for individual workshops.

orchestraplatform.org serves as the root domain for the entire platform ecosystem.

  • app.orchestraplatform.org
    • Main user interface
    • Workshop dashboard
    • User management
    • Workshop creation wizard
  • api.orchestraplatform.org
    • REST API endpoints
    • Authentication services
    • Workshop management operations
    • Status and monitoring endpoints
  • docs.orchestraplatform.org
    • User guides and tutorials
    • API documentation
    • Developer resources
    • Platform architecture

Each workshop instance receives a unique subdomain following a consistent naming pattern:

{workshop-id}.orchestraplatform.org

{course-type}-{identifier}-{random-suffix}

Examples:

  • rnaseq-intro-march2025-a1b2c3.orchestraplatform.org
  • genomics-advanced-cohort12-x9y8z7.orchestraplatform.org
  • proteomics-basics-workshop1-m5n6o7.orchestraplatform.org
  • Memorability: Clear, descriptive workshop names
  • Uniqueness: Random suffix prevents collisions
  • Organization: Course type enables easy categorization
  • Scalability: Supports unlimited workshop instances
  • status.orchestraplatform.org
    • Platform health dashboard
    • Service uptime monitoring
    • Performance metrics
    • Incident reporting
  • admin.orchestraplatform.org
    • Operator dashboard
    • System configuration
    • User management
    • Resource monitoring
  • staging.orchestraplatform.org
    • Pre-production testing
    • Feature validation
    • Integration testing
    • Performance testing
*.orchestraplatform.org → Kubernetes Ingress Controller

This configuration allows dynamic creation of workshop subdomains without manual DNS updates.

  • Automatic certificate provisioning via cert-manager
  • Let’s Encrypt integration for trusted certificates
  • Wildcard certificate support for all subdomains

The Kubernetes ingress controller uses host-based routing to direct traffic:

# Example ingress configuration
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: workshop-ingress
spec:
rules:
- host: genomics-101-abc123.orchestraplatform.org
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: genomics-101-abc123-service
port:
number: 8787
  • Geographic load balancing for global availability
  • Session affinity for workshop continuity
  • Health check integration for automatic failover
  • Strict hostname validation in ingress controllers
  • Prevention of subdomain hijacking
  • Regular certificate rotation
  • Per-subdomain access policies
  • Workshop-specific authentication
  • Network isolation between workshops
  • Traffic patterns by subdomain
  • Workshop usage analytics
  • Performance monitoring per domain
  • Error rate tracking
  • DNS propagation verification
  • Certificate expiration alerts
  • Subdomain availability checks