> For the complete documentation index, see [llms.txt](https://docs.stackai.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.stackai.com/technical-reference/deployment-models-and-terminology.md). # Deployment Models and Terminology A deployment model determines where StackAI runs, how its infrastructure is shared, and who operates it. Choose a model based on your isolation requirements, network boundaries, and ability to maintain the environment. This reference covers Multi-Tenant Cloud, Single-Tenant, Private Cloud (BYOC), and on-premise deployments. Confirm the available cloud provider, region, capabilities, and operating arrangement with StackAI before planning a rollout. ## Terms | Term | Meaning | | ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Tenant | An organization using the service within an isolation boundary. | | Multi-tenant | Multiple organizations use shared infrastructure. Logical controls separate each organization's data and access. | | Single-Tenant | StackAI's dedicated, StackAI-hosted offering. StackAI hosts and operates an environment for one customer. | | BYOC | Bring Your Own Cloud. StackAI runs in your organization's cloud account or subscription. StackAI also calls this Private Cloud. | | On-premise | StackAI runs in infrastructure your organization controls, such as its own data center. Specify the actual hosting location when discussing this option. | | Air-gapped | An environment with no direct external network connectivity. This is a connectivity requirement, not another name for every on-premise installation. | | VPC / VNet | A logically isolated network within a cloud account. AWS uses VPC; Azure uses VNet. A private network does not, by itself, identify the account owner or prohibit outbound requests. | | Control plane | The management functions used to deploy, update, configure, and monitor the installation. | | Data plane | The components that execute workloads and process or store application data. | | IAM | Identity and Access Management. Roles and policies determine which people and services can access cloud resources. | | Data residency | The geographic locations where data is stored or processed. Include backups, logs, and external services when assessing it. | | Data sovereignty | Requirements concerning the jurisdictions and legal controls that apply to data. Location is one part of this assessment. | **Separate three decisions:** tenancy describes sharing, hosting describes location and ownership, and management describes who operates the installation. In this documentation, **Single-Tenant** names the StackAI-hosted offering. **BYOC** names the customer-cloud offering, with approved access granted to StackAI. ## Compare the options | Model | Infrastructure boundary | Operating arrangement | Main reason to choose it | | -------------------- | ------------------------------------------------------------------- | --------------------------------------------------------------------------------------- | --------------------------------------------------------------------- | | Multi-Tenant Cloud | Shared StackAI-hosted infrastructure with logical tenant isolation | StackAI operates the platform | Start without provisioning or maintaining infrastructure | | Single-Tenant | Infrastructure dedicated to your organization and hosted by StackAI | StackAI operates the dedicated installation | Obtain a dedicated environment without taking on platform operations | | Private Cloud (BYOC) | Your cloud account or subscription | StackAI operates the software through approved access; your team owns the cloud account | Apply your cloud account, network, and infrastructure policies | | On-premise | Your organization's controlled infrastructure | Your team operates the installation with StackAI support under the agreed arrangement | Meet requirements for local infrastructure or restricted connectivity | ## Multi-Tenant Cloud ### How it works Your organization uses StackAI's shared cloud service. Data and access are separated logically between organizations. StackAI handles platform deployment, monitoring, maintenance, and upgrades. You do not need a cloud account or Kubernetes cluster to use it. ### When to choose it Use this option when a managed cloud service meets your requirements and your priority is to start building without infrastructure work. It is a practical choice when your team does not need a dedicated installation or control over the underlying cloud account. ### Operational implications Your administrators still manage members, roles, connections, and application access. Shared infrastructure does not mean shared access to another organization's data. You use the service's available regions and managed release process. If you require a particular hosting location or maintenance arrangement, confirm that requirement before choosing this model. ## Single-Tenant ### How it works StackAI hosts and operates an environment dedicated to your organization. StackAI manages the cloud account, deployment, upgrades, monitoring, and maintenance. Your team does not need to supply its own cloud account to host the installation. ### When to choose it Choose Single-Tenant when you need dedicated infrastructure but want StackAI to run the platform. It can suit an organization whose security review requires a separate environment without requiring ownership of the hosting account. ### Operational implications Dedicated infrastructure and customer ownership are different requirements. This option provides a dedicated environment; it is not BYOC. Your security and IT teams may still need to configure identity access, review network connectivity, and approve integrations. Agree on the region, maintenance process, and support responsibilities during deployment planning. A dedicated environment does not remove the need for application-level permissions. ## Private Cloud (BYOC) ### How it works StackAI runs in your cloud account or subscription. Your organization controls the infrastructure boundary and its cloud policies. BYOC requires your organization to grant StackAI approved access to deploy, update, and support the installation. StackAI operates the software through that access. Your team owns the cloud account and manages the cloud policies and infrastructure responsibilities agreed during deployment planning. Define the authorized operators, permission scope, and access process before deployment. The BYOC offering described here requires this access; it is not a customer-operated option without StackAI access. ### When to choose it Choose BYOC when the installation must be inside your cloud account, use your network controls, or connect to private resources through an approved network path. It is also relevant when your organization already has a platform team and established cloud operations. ### Operational implications Your team must prepare the cloud environment, identity permissions, networking, storage, and DNS requirements agreed with StackAI. Budget for cloud resources and ongoing operational work as well as the product. Keep the agreed access available for deployment, maintenance, and support. If your policies or permissions change, coordinate with StackAI before revoking or restricting that access so operations are not interrupted. New self-hosted deployments use Kubernetes as the standard deployment platform. Confirm the supported distribution and sizing for your installation rather than treating a standalone Docker setup as equivalent. ## On-premise and air-gapped deployments ### How they work An on-premise installation runs on infrastructure controlled by your organization. Your team takes responsibility for operating the environment, with StackAI providing deployment guidance, release packages, and support under the agreed arrangement. An air-gapped installation adds a separate constraint: it cannot make direct external network connections. Updates and other required artifacts must enter through an approved offline transfer process. ### When to choose them Choose on-premise when your organization requires local infrastructure ownership or a hosting boundary that cloud options cannot meet. Require air-gapped operation only when the network policy calls for it. A private endpoint, a firewall, or the absence of public inbound access is not the same as an air gap. ### Operational implications Plan for capacity, monitoring, backups, recovery, certificates, upgrades, and incident response. Assign an owner for each responsibility before production use. For air-gapped operation, identify reachable model services, document-processing dependencies, and business systems. Features that depend on an external service require an approved alternative or cannot be used in that environment. Confirm the supported interfaces and feature set for the proposed installation. ## Data boundaries and external services Hosting StackAI in your account or data center does not automatically keep every request inside that boundary. A configured model provider, connector, webhook, or other external service can receive data as part of execution. Review the complete request path: 1. Identify the data submitted by users or retrieved from connected sources. 2. Identify where StackAI processes and stores it. 3. List the model endpoints and external tools the application calls. 4. Review destinations for outputs, logs, backups, and monitoring data. 5. Confirm permitted network routes and support access. Treat storage location, processing location, and external transmission as separate questions. Model selection and deployment selection must work together to satisfy your requirements. ## Choose a deployment model Start with the requirement that cannot change. | Your requirement | Option to evaluate first | | ------------------------------------------------------ | ------------------------------------------ | | Use a managed service without operating infrastructure | Multi-Tenant Cloud | | Use dedicated infrastructure while StackAI operates it | Single-Tenant | | Run inside your own cloud account or subscription | Private Cloud (BYOC) | | Run on organization-controlled local infrastructure | On-premise | | Prohibit direct external network connectivity | An explicitly scoped air-gapped deployment | Then agree on the operating plan: * **Location and isolation:** cloud account owner, region, network boundaries, and dedicated resources. * **Connectivity:** user access, identity provider, models, connectors, and outbound destinations. * **Operations:** owners for upgrades, monitoring, backups, recovery, and incident response. * **Support access:** permitted operators, permission scope, access duration, and diagnostic-data handling. * **Availability:** supported features, dependencies, capacity, and recovery requirements. * **Cost:** product subscription, infrastructure, external model usage, and staff time. A deployment model is not a compliance certification or a guarantee of feature parity. Confirm the controls and capabilities of the specific installation against your organization's requirements. ## Related resources * [Identity, Access, and Administration](/technical-reference/identity-access-and-administration.md) * [Releases and Environments](/technical-reference/releases-and-environments.md) * [Models, Agents, and Skills](/technical-reference/models-agents-and-skills.md) * [Connections and Tool Execution](/technical-reference/connections-and-tool-execution.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.stackai.com/technical-reference/deployment-models-and-terminology.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.