code · pull · Apr 29, 2026 · Apr 29, 2026 · Apr 29, 2026
diff --git a/docs-mintlify/admin/account-billing/pricing.mdx b/docs-mintlify/admin/account-billing/pricing.mdx
diff --git a/docs-mintlify/admin/deployment/auto-suspension.mdx b/docs-mintlify/admin/deployment/auto-suspension.mdx
@@ -23,7 +23,7 @@ deployments**. See [effects on experience][self-effects] for details.
 
 <Info>
 
-Auto-suspension is not avaiable for [production multi-clusters][ref-prod-multi-cluster].
+Auto-suspension is not avaiable for [Multi-cluster deployments][ref-prod-multi-cluster].
 
 </Info>
 
@@ -35,9 +35,9 @@ deployment when API requests start coming in again:
   <img src="https://ucarecdn.com/e9a22d59-e0af-40c5-b590-02f2566663d1/" alt="Cube Cloud auto-suspend flowchart" />
 </Frame>
 
-[Development instances][ref-deployment-dev-instance] are auto-suspended
-automatically when not in use for 30 minutes, whereas [production
-clusters][ref-deployment-prod-cluster] can auto-suspend after no API
+[Shared deployments][ref-deployment-dev-instance] are auto-suspended
+automatically when not in use for 30 minutes, whereas [Dedicated
+deployments][ref-deployment-prod-cluster] can auto-suspend after no API
 requests were received within a configurable time period.
 
 During auto-suspension, resources are monitored in 5 minute intervals. This
@@ -114,9 +114,9 @@ longer in certain situations depending on two major factors:
 Complex data models take more time to compile, and complex queries can cause
 response times to be significantly longer than usual.
 
-[ref-deployment-dev-instance]: /docs/deployment/cloud/deployment-types#development-instance
-[ref-deployment-prod-cluster]: /docs/deployment/cloud/deployment-types#production-cluster
-[ref-prod-multi-cluster]: /docs/deployment/cloud/deployment-types#production-multi-cluster
+[ref-deployment-dev-instance]: /docs/deployment/cloud/deployment-types#shared
+[ref-deployment-prod-cluster]: /docs/deployment/cloud/deployment-types#dedicated
+[ref-prod-multi-cluster]: /docs/deployment/cloud/deployment-types#multi-cluster
 [ref-deployment-pricing]: /admin/account-billing/pricing
 [ref-monitoring]: /admin/deployment/monitoring-integrations
 [ref-data-model]: /docs/data-modeling/overview

diff --git a/docs-mintlify/admin/deployment/continuous-deployment.mdx b/docs-mintlify/admin/deployment/continuous-deployment.mdx
@@ -48,71 +48,3 @@ session prior to connecting to your GitHub account from Cube.
 
 Cube Cloud will automatically deploy from the specified production branch
 (`master` by default).
-
-## Deploy with CLI
-
-<Warning>
-
-Enabling this option will cause the **Data Model** page to display the
-last known state of a Git-based codebase (if available), instead of reflecting
-the latest modifications made. It is important to note that the logic will still
-be updated in both the API and the Playground.
-
-</Warning>
-
-You can use [the CLI][ref-workspace-cli] to set up continuous deployment for a
-Git repository. You can also use it to manually deploy changes without
-continuous deployment.
-
-### Manual Deploys
-
-You can deploy your Cube project manually. This method uploads data models and
-configuration files directly from your local project directory.
-
-You can obtain a Cube Cloud deploy token from your
-deployment's **Settings** screen.
-
-```bash
-npx cubejs-cli deploy --token TOKEN
-```
-
-### Continuous Deployment
-
-You can use Cube CLI with your continuous integration tool.
-
-<Info>
-
-You can use the `CUBE_CLOUD_DEPLOY_AUTH` environment variable to pass the Cube
-Cloud deploy token to Cube CLI.
-
-</Info>
-
-Below is an example configuration for GitHub Actions:
-
-```yaml
-name: My Cube App
-on:
-  push:
-    paths:
-      - "**"
-    branches:
-      - "master"
-jobs:
-  deploy:
-    name: Deploy My Cube App
-    runs-on: ubuntu-latest
-    timeout-minutes: 30
-    steps:
-      - name: Checkout
-        uses: actions/checkout@v2
-      - name: Use Node.js 20.x
-        uses: actions/setup-node@v1
-        with:
-          node-version: 20.x
-      - name: Install Cube backend server core
-        run: npm i @cubejs-backend/server-core
-      - name: Deploy to Cube Cloud
-        run: npx cubejs-cli deploy --token ${{ secrets.CUBE_CLOUD_DEPLOY_AUTH }}
-```
-
-[ref-workspace-cli]: /docs/workspace/cli
diff --git a/docs-mintlify/admin/deployment/deployment-types.mdx b/docs-mintlify/admin/deployment/deployment-types.mdx
@@ -1,79 +1,72 @@
 ---
 title: Deployment types
 sidebarTitle: Deployment types
-description: "Cube provides three deployment types: Development, Production, and Multi-cluster."
+description: "Cube provides three deployment types: Shared, Dedicated, and Multi-cluster."
 ---
 
-* [Development](#development) — designed for development use cases.
-* [Production](#production) — designed for production workloads and
-high-availability.
+* [Shared](#shared) — designed for development use cases. Runs on compute
+shared with other deployments within the selected region.
+* [Dedicated](#dedicated) — designed for production workloads and
+high-availability. Runs on compute dedicated to your deployment.
 * [Multi-cluster](#multi-cluster) — designed for demanding production workloads,
 high-scalability, high-availability, and advanced multi-tenancy configurations.
+Runs on multiple Dedicated deployments.
 
-## Development
+## Shared {#shared}
 
 <Info>
 
 Available for free, no credit card required. Your free trial is limited to 2
-development deployments and only 1,000 queries per day. Upgrade to
+Shared deployments and only 1,000 queries per day. Upgrade to
 [any paid plan](https://cube.dev/pricing) to unlock all features.
 
 </Info>
 
-<div style={{ textAlign: "center" }}>
-  <img
-    alt="High-level architecture diagram of a Development deployment"
-    src="https://ucarecdn.com/adaa000a-c562-4eb4-9687-6f57f0f4c22b/"
-    style={{ border: "none" }}
-    width="100%"
-  />
-</div>
 
-Development deployments are designed for development use cases only. This makes
+Shared deployments run on compute shared with other deployments within the
+selected region, which keeps the cost low but means resources aren't reserved
+for you exclusively.
+
+Shared deployments are designed for development use cases only. This makes
 it easy to get started with Cube quickly, and also allows you to build and
 query pre-aggregations on-demand.
 
-Development deployments don't have dedicated [refresh workers][ref-refresh-worker]
+Shared deployments don't have dedicated [refresh workers][ref-refresh-worker]
 and, consequently, they do not refresh pre-aggregations on schedule.
 
-Development deployments do not provide high-availability nor do they guarantee
-fast response times. Development deployments also [auto-suspend][ref-auto-sus]
+Shared deployments do not provide high-availability nor do they guarantee
+fast response times. Shared deployments also [auto-suspend][ref-auto-sus]
 after 30 minutes of inactivity, which can cause the first request after the
 deployment wakes up to take additional time to process. They also have
 [limits][ref-limits] on the maximum number of queries per day and the maximum
-number of Cube Store Workers. We **strongly** advise not using a Development
+number of Cube Store Workers. We **strongly** advise not using a Shared
 deployment in a production environment, it is for testing and learning about
 Cube only and will not deliver a production-level experience for your users.
 
-You can try a Development deployment by
+You can try a Shared deployment by
 [signing up for Cube](https://cubecloud.dev/auth/signup) to try it free
 (no credit card required).
 
-## Production
+## Dedicated {#dedicated}
 
 <Info>
 
 Available on [all paid plans](https://cube.dev/pricing).
 
 </Info>
 
-<div style={{ textAlign: "center" }}>
-  <img
-    alt="High-level architecture diagram of a Production deployment"
-    src="https://ucarecdn.com/fcb57d7a-09ee-4854-9282-db443a5ee61d/"
-    style={{ border: "none" }}
-    width="100%"
-  />
-</div>
 
-Production deployments are designed to support high-availability production
+Dedicated deployments run on compute dedicated exclusively to your deployment,
+giving you predictable performance and full control over capacity.
+
+Dedicated deployments are designed to support high-availability production
 workloads. It consists of several key components, including starting with 2 Cube
 API instances, 1 Cube Refresh Worker and 2 Cube Store Routers - all of which run
 on dedicated infrastructure. The deployment can automatically scale to meet the
 needs of your workload by adding more components as necessary; check the page on
 [scalability][ref-scalability] to learn more.
 
-## Multi-cluster
+## Multi-cluster {#multi-cluster}
 
 Multi-cluster deployments are designed for demanding production workloads,
 high-scalability, high-availability, and large [multi-tenancy][ref-multitenancy]
@@ -86,54 +79,38 @@ Available on [Premium and above plans](https://cube.dev/pricing).
 </Info>
 
 It provides you with two options:
-* Scale the number of [Production](#production) deployments serving your
-workload, allowing to route requests over up to 10 production deployments and
+* Scale the number of [Dedicated](#dedicated) deployments serving your
+workload, allowing to route requests over up to 10 Dedicated deployments and
 up to 100 API instances.
 * Optionally, scale the number of Cube Store routers, allowing for increased
 Cube Store querying performance.
 
-<div style={{ textAlign: "center" }}>
-  <img
-    alt="High-level architecture diagram of a Multi-cluster deployment"
-    src="https://ucarecdn.com/0ab1eb5c-7aba-4e9c-8951-1998d4b714f0/"
-    style={{ border: "none" }}
-    width="100%"
-  />
-</div>
 
-Each production deployment is billed separately, and all production deployments
+Each Dedicated deployment is billed separately, and all Dedicated deployments
 can use auto-scaling to match demand.
 
 ### Configuring Multi-cluster
 
 To switch your deployment to Multi-cluster, navigate to
 **Settings → General**, select it under **Type**, and confirm
-with **✓**:
-
-<Frame>
-  <img src="https://ucarecdn.com/30e357ce-4252-4676-bb1d-e46eb1f753ef/" />
-</Frame>
+with **✓**.
 
-To set the number of production deployments within your Multi-cluster
+To set the number of Dedicated deployments within your Multi-cluster
 deployment, navigate to **Settings → Configuration** and edit
 **Number of clusters**.
 
-<Frame>
-  <img src="https://ucarecdn.com/1da76aca-200a-410a-b84c-59b3d14ced9f/" />
-</Frame>
+### Routing traffic between Dedicated deployments
 
-### Routing traffic between production deployments
-
-Cube routes requests between multiple production deployments within a
+Cube routes requests between multiple Dedicated deployments within a
 Multi-cluster deployment based on [`context_to_app_id`][ref-ctx-to-app-id].
 In most cases, it should return an identifier that does not change over time
 for each tenant.
 
 The following implementation will make sure that all requests from a
-particular tenant are always routed to the same production deployment. This
-approach ensures that only one production deployment keeps compiled data model
+particular tenant are always routed to the same Dedicated deployment. This
+approach ensures that only one Dedicated deployment keeps compiled data model
 cache for each tenant and serves its requests. It allows to reduce the
-footprint of the compiled data model cache on individual production deployments.
+footprint of the compiled data model cache on individual Dedicated deployments.
 
 <CodeGroup>
 
@@ -159,7 +136,7 @@ module.exports = {
 
 If your implementation of `context_to_app_id` returns identifiers that change
 over time for each tenant, requests from one tenant would likely hit multiple
-production deployments and you would not have the benefit of reduced memory
+Dedicated deployments and you would not have the benefit of reduced memory
 footprint. Also you might see 502 or timeout errors in case of different
 deployment nodes would return different `context_to_app_id` results for the
 same request.
@@ -169,11 +146,7 @@ same request.
 ## Switching between deployment types
 
 To switch a deployment's type, go to the deployment's **Settings** screen
-and select from the available options:
-
-<Frame>
-  <img src="https://ucarecdn.com/fbde6a1e-734a-4091-8edd-922dc1ee7e1c/" alt="Deployment Settings page showing Development, Production, and Multi-cluster options" />
-</Frame>
+and select from the available options.
 
 [ref-ctx-to-app-id]: /reference/configuration/config#context_to_app_id
 [ref-limits]: /docs/deployment/cloud/limits#resources

diff --git a/docs-mintlify/admin/deployment/environments.mdx b/docs-mintlify/admin/deployment/environments.mdx
@@ -25,7 +25,7 @@ The production environment is _always available_ unless [suspended][ref-suspend]
 ### Resources and costs
 
 Depending on the [deployment type][ref-deployment-types], the production environment
-either runs on a development instance or on a production cluster with [multiple API
+either runs on a Shared deployment or on a Dedicated deployment with [multiple API
 instances][ref-api-instance-scalability], incurring [relevant
 costs][ref-pricing-deployment-tiers].
 
@@ -59,7 +59,7 @@ regardless of user activity.
 
 ### Resources and costs
 
-Staging environments run on development instances, incurring [relevant
+Staging environments run on Shared deployments, incurring [relevant
 costs][ref-pricing-deployment-tiers]. However, they automatically suspend after 10 minutes
 of inactivity, regardless of the [availability](#availability) setting, so you are only
 charged for the time when staging environments are being used.
@@ -83,7 +83,7 @@ development mode. Otherwise, queries to this environment will fail.
 
 ### Resources and costs
 
-Development environments run on development instances, incurring [relevant
+Development environments run on Shared deployments, incurring [relevant
 costs][ref-pricing-deployment-tiers]. However, they automatically suspend after 10 minutes
 of inactivity, so you are only charged for the time when development environments are
 being used.

diff --git a/docs-mintlify/admin/deployment/index.mdx b/docs-mintlify/admin/deployment/index.mdx
@@ -173,8 +173,8 @@ Cube Cloud deployments only consume resources when they are needed to run worklo
 
 * For the [production environment][ref-environments-prod], resources are always consumed
 unless a deployment is [suspended][ref-auto-sus].
-* For any other [environment][ref-environments], a development instance is allocated
-while it's active. After a period of inactivity, the development instance is deallocated.
+* For any other [environment][ref-environments], a Shared deployment is allocated
+while it's active. After a period of inactivity, the Shared deployment is deallocated.
 * For pre-aggregations, Cube Store workers are allocated while there's some
   activity related to pre-aggregations, e.g., API endpoints are serving
   requests to pre-aggregations, pre-aggregations are being built, etc.

diff --git a/docs-mintlify/admin/deployment/limits.mdx b/docs-mintlify/admin/deployment/limits.mdx
@@ -29,8 +29,8 @@ types][ref-deployment-types] and [product tiers][ref-pricing]:
 | Number of deployments                                                               |     2     | Unlimited | Unlimited | Unlimited  |
 | Number of API instances per deployment                                              |     1     |    10     |    10     | [Contact us][cube-contact-us] |
 | Number of Cube Store workers per deployment                                         |     2     |    16     |    16     | [Contact us][cube-contact-us] |
-| Queries per day for each [development instance][ref-dev-instance]                   |   1,000   |  10,000   | Unlimited | Unlimited  |
-| Queries per day for each [production cluster][ref-prod-cluster]                     |     —     |  50,000   | Unlimited | Unlimited  |
+| Queries per day for each [Shared deployment][ref-dev-instance]                      |   1,000   |  10,000   | Unlimited | Unlimited  |
+| Queries per day for each [Dedicated deployment][ref-prod-cluster]                   |     —     |  50,000   | Unlimited | Unlimited  |
 | [Query History][ref-query-history] — retention period                               |   1 day   | Depends on the [tier][ref-query-history-tiers] | Depends on the [tier][ref-query-history-tiers] | Depends on the [tier][ref-query-history-tiers] |
 | [Query History][ref-query-history] — queries processed per day for each deployment  |   1,000   | Depends on the [tier][ref-query-history-tiers] | Depends on the [tier][ref-query-history-tiers] | Depends on the [tier][ref-query-history-tiers] |
 | [Audit Log][ref-audit-log] — retention period                                       |     —     |     —     |     —     | 30 days    |
@@ -58,7 +58,7 @@ This is a hard limit. Usage is calculated per Cube Cloud account, i.e., in total
 for all deployments within an account.
 
 When a threshold is hit, further queries will not be processed. In that case,
-consider upgrading a development instance to a production cluster.
+consider upgrading a Shared deployment to a Dedicated deployment.
 Alternatively, consider upgrading to [another tier][ref-pricing].
 
 ### Queries processed by Query History per day
@@ -101,8 +101,8 @@ response.
 [ref-pricing]: /admin/account-billing/pricing
 [ref-query-history]: /admin/monitoring/query-history
 [ref-monitoring-integrations]: /admin/deployment/monitoring-integrations
-[ref-dev-instance]: /docs/deployment/cloud/deployment-types#development-instance
-[ref-prod-cluster]: /docs/deployment/cloud/deployment-types#production-cluster
+[ref-dev-instance]: /docs/deployment/cloud/deployment-types#shared
+[ref-prod-cluster]: /docs/deployment/cloud/deployment-types#dedicated
 [cube-contact-us]: https://cube.dev/contact
 [ref-query-history-tiers]: /admin/account-billing/pricing#query-history-tiers
 [ref-audit-log]: /admin/monitoring/audit-log

diff --git a/docs-mintlify/admin/deployment/scalability.mdx b/docs-mintlify/admin/deployment/scalability.mdx
@@ -5,17 +5,17 @@ description: Tune Cube Cloud throughput and pre-aggregation capacity by scaling
 
 Cube Cloud also allows adding additional infrastructure to your deployment to
 increase scalability and performance beyond what is available with each
-Production Deployment.
+Dedicated deployment.
 
 ## Auto-scaling of API instances
 
-With a Production Cluster, 2 Cube API Instances are included. That said, it
+With a Dedicated deployment, 2 Cube API Instances are included. That said, it
 is very common to use more, and [additional API instances][ref-limits] can be
 added to your deployment to increase the throughput of your queries. A rough
 estimate is that 1 Cube API Instance is needed for every 5-10
 requests-per-second served. Cube API Instances can also auto-scale as needed.
 
-To change how many Cube API instances are available in the Production Cluster,
+To change how many Cube API instances are available in the Dedicated deployment,
 go to the deployment’s **Settings** screen, and open
 the **Configuration** tab. From this screen, you can set the minimum and
 maximum number of Cube API instances for a deployment: