Docs
  • Solver
  • Models
    • Field Service Routing
    • Employee Shift Scheduling
    • Pick-up and Delivery Routing
  • Platform
Try models
  • Timefold Platform
  • API integration
  • Integration scenarios
  • Multiple environments and clusters

Timefold Platform

    • Introduction
    • Scheduling API concepts
    • Getting started with the Timefold Platform
    • Platform concepts
    • Models
      • Model catalog and documentation
      • Model maturity and versioning
      • Trialing Timefold models
    • How-tos
      • Dataset lifecycle
      • Interpreting dataset results
      • Configuration parameters and profiles
      • Reviewing the audit log
      • Searching and categorizing datasets for auditability
      • Member management and roles
      • Secrets management
      • Solve queue
      • Using the maps service
      • Comparing datasets (preview)
      • Insights (preview)
      • Real-time planning with /from-patch (preview)
    • Job-oriented guides
      • Balancing different optimization goals
      • Validating an optimized plan with Explainable AI
      • Uncovering inefficiencies in operational planning
      • Responding to disruptions with real-time planning
      • Designing better routing plans with (just enough) traffic awareness
    • API integration
      • Model API usage
      • Receiving model API results
        • Webhooks
        • Server sent events (SSE)
        • Polling
      • Handling changes to your planning data
      • Integration scenarios
        • Multiple environments and clusters
        • Data residency requirements
        • Air-gapped environments
      • Platform API usage
    • Changelog
    • Feature requests
    • Self-Hosted
      • Self-Hosted vs. Timefold Cloud Platform
      • Installation instructions
      • Upgrade instructions
      • Troubleshooting
    • Support
      • Contacting support
      • Platform status
      • Troubleshooting
    • Trust
      • Risk profile
      • Product security
      • Data security
      • Legal and privacy
      • AI legislation compliance
      • Trust center

Multiple environments and clusters

Software teams typically run multiple instances of their own application. At minimum a production environment and one or more non-production environments such as development, staging, or UAT. When that application integrates with the Timefold Platform, each environment needs its own isolated Timefold context so that test data, API keys, and configuration don’t bleed into production.

You may also run geographically distributed deployments: separate application clusters per region, per your own customer, or per business unit. This page describes how to architect for these situations.

Tenants provide isolation

The Timefold Platform uses tenants as the primary isolation boundary. Within a single platform installation:

  • Each tenant has its own models, datasets, members, API keys, webhooks, and configuration profiles.

  • Members only see the data of tenants they belong to.

  • Data from one tenant is never visible to another tenant, enforced at both the database and application level.

A member can belong to multiple tenants and switch between them in the UI.

This means you don’t need separate platform installations to isolate environments: you need separate tenants.

Recommended approach: multiple tenants on Timefold Cloud

Use Timefold Cloud and create one tenant per environment.

For example:

Environment Timefold tenant API key used by

Production

acme-prod

Production application cluster

Staging

acme-staging

Staging application cluster

Development

acme-dev

Development environment

Each environment of your application is configured with the API key for its corresponding tenant. Developers and QA engineers work in non-production tenants; production traffic never touches the same tenant as test datasets.

Why this is the right approach

Zero infrastructure overhead

No additional clusters or infrastructure to manage. Creating a new tenant takes minutes.

Full isolation per environment

Datasets, API keys, configuration profiles, and audit logs are all scoped to the tenant.

Independent configuration

Each tenant can have its own configuration profiles and model settings, which lets staging mirror production configuration while development uses faster, looser solver settings.

UI access for all environments

Developers can use the full Timefold UI to debug their integration in the development or staging tenant, using the same visualization and troubleshooting tools available for production.

Member access control

Production access can be restricted to administrators, while developers have full access to non-production tenants.

Multiple geographic regions

If your application runs in both the EU and the US, point each regional cluster at the appropriate Timefold Cloud endpoint while still using separate tenants per environment:

Application cluster Timefold endpoint Tenant

EU production

app.timefold.ai

acme-eu-prod

EU staging

app.timefold.ai

acme-eu-staging

US production

app-us1.timefold.ai

acme-us-prod

US staging

app-us1.timefold.ai

acme-us-staging

app.timefold.ai and app-us1.timefold.ai are separate platform installations with separate tenant namespaces. A tenant named acme-prod on the EU endpoint is independent of any identically named tenant on the US endpoint.

Self-hosted: single-tenant limitation

If you’re self-hosting, be aware that the self-hosted platform is single-tenant only. Each installation supports exactly one tenant. This means:

  • If you want separate production and staging environments, you must operate two separate self-hosted installations.

  • Each installation requires its own Kubernetes cluster, OpenID Connect configuration, data store, DNS name, and TLS certificate.

  • Maintenance effort roughly doubles for each additional installation.

This is one of the key operational cost differences between self-hosting and Timefold Cloud. If you’re self-hosting and need multiple environments, consider migrating to Timefold Cloud, where this is handled natively.

Summary

Need Recommended approach

Separate dev / staging / prod environments

One tenant per environment on Timefold Cloud

EU and US regional isolation

app.timefold.ai for EU tenants, app-us1.timefold.ai for US tenants

Other regional isolation

Contact Timefold: a Managed service may be available for specific regions

Fully isolated per-customer deployments (ISV model)

One tenant per customer on Timefold Cloud, contact us if dedicated infrastructure is needed

Self-hosted with multiple environments

Separate platform installation per environment (high operational cost)

Next

  • Data residency requirements

  • Air-gapped environments

  • Member management and roles

  • Platform concepts

  • © 2026 Timefold BV
  • Timefold.ai
  • Documentation
  • Changelog
  • Send feedback
  • Privacy
  • Legal
    • Light mode
    • Dark mode
    • System default