Instances and workspaces

Prev Next
  • You will learn:
    • A high-level overview of Tulip Instances & Tulip Workspaces.
    • Fundamental instance vs. workspace architecture considerations for multi-site multi-region customers.

Instances

A Tulip Instance is a dedicated environment where your organization accesses the Tulip platform. Each instance has a unique URL: [your-account].tulip.co

Workspaces

Who can use this feature

Users on Enterprise plans and above.

Tulip Workspaces help large organizations manage multiple factory sites within a single Tulip instance. Think of workspaces as separate areas within your main Tulip environment—each with its own users, apps, and data.

Use cases for workspaces

To learn more about use cases for Workspaces, see Workspaces configuration. This shows what information is configured at an Instance (Account) level, and what can be configured at a Workspace level.

Instance infrastructure

Cloud infrastructure regions

Any given Tulip instance runs in the cloud on a cloud provider's infrastructure in a specific region.
Tulip currently uses infrastructure to host Tulip instances in the following regions:

  • North America
  • Europe
  • Southeast Asia
  • China

Supporting other regions:
Factories in other regions are typically hosted on infrastructure from the nearest available region. For example, a factory in India would use our Southeast Asia infrastructure.

Tulip platform versions

Any given Tulip instance runs one specific version of the Tulip platform.

  • Instances for general manufacturing customers are typically on a weekly release cycle.
  • Instances for customers in regulated industries (e.g. life sciences, aerospace and defense) are typically on our Long-Term Support LTS release cycle.
    • Note: new LTS versions are not automatically deployed to customer instances. LTS-version customers coordinate upgrades with Tulip Support.

Workspace infrastructure

  • All Workspaces in a Tulip instance run:
    • in the same cloud provider infrastructure in the same region
    • on the same version of the Tulip platform

Visual representation

The below image shows an example of a customer's production instances separated by region and workspace:

instances & workspaces by geo 1.svg

Architecture considerations for multi-site customers

Early in a multi-site customer's adoption of the Tulip platform there is typically some discussion and decision by the customer regarding whether to use separate Workspaces per physical site or separate Instances. The chosen architecture is typically a result of the following factors:

Geographic distribution

  • One instance = one cloud infrastructure region
    • Multi-site customers with factories in multiple regions are generally best served with separate instance(s) per region, as this would help ensure optimal performance.

Workspace limits & capabilities

For workspace limits, see here.

  • The configuration capabilities of the Workspaces feature (i.e. what can be configured at an instance-level vs. workspace-level).
  • Tulip Player and workspace registration limitation
    • Tulip Player on a given workstation can be registered to multiple instances. A user can switch between instances using the option 'Developer / Change Server' and adding or selecting another instance.
    • Once Tulip Player is registered to an instance, it remains connected to the specific workspace where it was first registered.
      • For operators at a production site this is generally a non-issue.
      • Impact to App builders
        • App builders supporting multiple sites on a single instance separated by Workspaces face workflow disruptions.
        • Tulip Player workspace switching requires data clearing and re-registration on the instance to their desired workspace.

Platform version requirements

  • All Workspaces in an instance share the same platform version.
  • Regulated industry customers using LTS versions should consider separate instances per site to avoid upgrade coordination delays:
    • New LTS releases are not automatically pushed to customer instances.
    • LTS customers qualify new LTS releases then coordinate with Tulip Support to upgrade their instance(s).
    • If a regulated industry customer used a single production instance for a given region (and used Workspaces to segment the individual sites), the LTS upgrade would be delayed until all sites have qualified the new LTS version and are ready to upgrade.
    • Thus, most regulated industry customers running LTS versions opt to establish a separate production instance per physical site.
  • App Life Cycle Management
    • A Tulip app can only be imported into a workspace or instance running the same platform version as the instance/workspace from which the app was exported.
    • See more details on 'Export & Import' here.

User limits

See user management limits here.

Multi-site architecture guide and best practices

  • Same Region and < 15 Sites: Consider using Workspaces
  • Multiple Regions: Use separate Instances per region
  • Regulated Industry: Use separate Instances per site

If you have any questions on instance/workspace architectural strategy, reach out to:

  • Your Presales Engineer (if currently evaluating the Tulip platform)
  • Your Tulip Professional Services team (if you are currently engaged in a Tulip Professional Services project)
  • Your Customer Success Manager and/or Technical Account Manager (for onboarded/existing customers)