docs: rename deployment types shared dedicated (cube-js#10769)

* docs: rename deployment types to Shared and Dedicated

Renames the Cube Cloud deployment types in the Mintlify docs:
Development -> Shared (compute shared with other Cube customers)
Production  -> Dedicated (compute dedicated to your deployment)
Multi-cluster keeps its short name; the legacy "Production
multi-cluster" form becomes "Multi-cluster deployment" /
"Dedicated multi-cluster" since multi-cluster scales Dedicated
deployments.

The canonical deployment-types page gets explicit heading IDs
({#shared}, {#dedicated}, {#multi-cluster}) and a brief
high-level explanation of what "shared" vs "dedicated" means
for compute, in the intro bullets and at the top of each
section.

All in-repo cross-references (pricing, deployment admin pages,
monitoring, semantic-layer-sync, refreshing pre-aggregations)
are updated to the new anchors. Internal markdown link-reference
keys (e.g. ref-production-cluster) are kept as-is to minimize
churn; only the URL fragments change.

Out of scope: legacy /docs Next.js site, .cursor/rules/namings-rule.mdc,
docs.json redirects, and the Contentful screenshots that still
show the old names visually (alt text is updated).

Made-with: Cursor

* docs: clarify Shared deployment compute wording

Per Pavel's feedback, "shared with other Cube customers" is
inaccurate (in dedicated-infra setups it's only shared within
the account) and uncomfortable for customers with dedicated
infrastructure. Reword to "shared with other deployments within
the selected region", which is accurate in both cases.

Made-with: Cursor

* docs: remove outdated screenshots and CLI deploy section

- deployment-types.mdx: drop the three Settings screenshots; the
  surrounding instructions read fine without them.
- continuous-deployment.mdx: drop the entire "Deploy with CLI"
  section (Manual Deploys + Continuous Deployment subsections,
  and the orphan ref-workspace-cli link); the CLI deploy flow
  is no longer recommended.

Made-with: Cursor

Author: keydunov

docs-mintlify/admin/account-billing/pricing.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

docs-mintlify/admin/deployment/auto-suspension.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

docs-mintlify/admin/deployment/continuous-deployment.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

docs-mintlify/admin/deployment/deployment-types.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.

docs-mintlify/admin/deployment/environments.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.

docs-mintlify/admin/deployment/index.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

docs-mintlify/admin/deployment/limits.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: