--- title: "Instances and workspaces" slug: "instances-and-workspaces" updated: 2025-10-28T18:06:37Z published: 2025-10-28T18:06:37Z --- > ## Documentation Index > Fetch the complete documentation index at: https://support.tulip.co/llms.txt > Use this file to discover all available pages before exploring further. # Instances and workspaces - 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](/r230/docs/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](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/instances%20&%20workspaces%20by%20geo%20%281%29%281%29.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](/r230/docs/workspace-management#limits). - The [configuration capabilities of the Workspaces feature](/r230/docs/workspaces#configuration) (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](/r230/docs/export-import). ### User limits See user management limits [here](/r230/docs/user-management#user-management-limits). ## 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) **Tulip Instance** A Tulip customer account. Your instance can be found at https://[your-instance].tulip.co When *your instance*is referenced, we are just talking about your Tulip account on an organization-level, not user-level. **Workspace** **Workspaces**are a model within Tulip to separate Tulip assets to match the places where work is being done. A workspace should represent a single facility, line, or department. With workspaces, users across facilities can easily collaborate, share their solutions, and improve their global operations. **Long Term Support** **LTS** or **Long Term Support** is a product lifecycle management policy where the software is maintained longer than the standard cycle. This software maintenance cycle is typically for customers in highly regulated environments to reduce the introduction of new risks that come with new software and patch releases.