website-and-documentation/content/en/docs/edp/deployment/otc/environments.md
Patrick Sy ad0052c0a7
Some checks failed
build / build (push) Failing after 55s
ci / build (push) Successful in 56s
feat(otc): Added OTC overview and intro to deployments
2025-12-18 14:25:26 +01:00

2.2 KiB

title linkTitle weight description
EDP Environments in OTC Environments 10 Instances of EDP are deployed into distinct OTC environments

Architecture

Two distinct tenants are utilized within OTC to enforce a strict separation between production (prod) and non-production (non-prod) environments. This segregation ensures isolated resource management, security policies, and operational workflows, preventing any potential cross-contamination or impact between critical production systems and development/testing activities.

  • Production Tenant: This tenant is exclusively dedicated to production workloads and is bound to the primary domain buildth.ing. All production-facing EDP instances and associated infrastructure reside within this tenant, leveraging buildth.ing for public access and service discovery. Within this tenant, each EDP instance is typically dedicated to a specific customer. This design decision provides robust data separation, addressing critical privacy and compliance requirements by isolating customer data. It also allows for independent upgrade paths and maintenance windows for individual customer instances, minimizing impact on other customers while still benefiting from centralized management and deployment strategies. The primary edp.buildth.ing instance and the observability.buildth.ing instance are exceptions to this customer-dedicated model, serving foundational platform roles.
  • Non-Production Tenant: This tenant hosts all development, testing, and staging environments, bound to the primary domain t09.de. This setup allows for flexible experimentation and robust testing without impacting production stability.

Each tenant is designed to accommodate multiple instances of the product, EDP. These instances are dynamically provisioned and typically bound to specific subdomains, which inherit from their respective primary tenant domain (e.g., my-test.t09.de for a non-production instance or customer-a.buildth.ing for a production instance). This subdomain structure facilitates logical separation and routing for individual EDP deployments.