Skip to main content
Every Cube Cloud deployment provides a number of environments:

​
Production environment

This is the main environment. It runs the data model from the main branch.

​
Availability

The production environment is always available unless suspended.

​
Resources and costs

Depending on the deployment type, the production environment either runs on a Shared deployment or on a Dedicated deployment with multiple API instances, incurring relevant costs.

​
Cube version

Production environments run a Cube version from the selected update channel.

​
Staging environments

Staging environments are activated automatically for specific source code branches when a branch is switched to in the Cube Cloud UI. Any development mode changes must be committed to a branch to be available in this environment.

​
Availability

By default, they are only active and accessible while viewed by at least one user. When no users are viewing the branch, the environment becomes inactive and inaccessible. If you’d like to update this setting for a specific branch (e.g., for testing purposes), go to Settings → Staging Environments and check the toggle next to it:
  • Toggle off (default). A staging environment is only active when viewed by users. When no users are viewing the branch, queries to this environment will fail.
  • Toggle on. A staging environment remains always active and accessible, regardless of user activity.
The same toggle is available in the CLI and the Control Plane API, so it can be scripted, e.g. from CI:
A staging environment can also be the target of an embed session: pass its branch name as branchName and the embedded content queries that branch’s data model. With the toggle on, the session is generated whether or not the environment has suspended for inactivity; with it off, it fails unless someone is viewing the branch at that moment.

​
Resources and costs

Staging environments run on Shared deployments, incurring relevant costs. However, they automatically suspend after 10 minutes of inactivity, regardless of the availability setting, so you are only charged for the time when staging environments are being used.

​
Cube version

Staging environments always run the most up-to-date Cube version.

​
Development environments

A development environment is activated automatically when a user enters the development mode on a specific branch of the source code. It updates automatically when a user saves changes to the data model. Only one development environment is allocated per user.

​
Availability

A development environment is only active and accessible while viewed by a user in the development mode. Otherwise, queries to this environment will fail.

​
Resources and costs

Development environments run on Shared deployments, incurring relevant costs. However, they automatically suspend after 10 minutes of inactivity, so you are only charged for the time when development environments are being used.

​
Cube version

Development environments always run the most up-to-date Cube version.

​
Pre-aggregations

All environments of a deployment share the same Cube Store and the same pre-aggregations schema. There is no separate schema for staging or development environments, and the branch name is not part of a pre-aggregation table name. Cube tells pre-aggregation tables apart by the definition that produced them, so tables built from different branches coexist in the shared schema:
  • A branch that leaves a pre-aggregation unchanged is served from the tables the production environment has already built. If the pre-aggregation’s refresh key has changed, a query from the branch can start a background refresh of it, and the production environment then serves the newly built table too.
  • A branch that changes a pre-aggregation, for example by adding a dimension or editing a measure, builds its own tables next to the production ones. The production environment keeps using its own tables and never serves the tables built for the changed definition.
  • Once the branch is merged, the production environment can reuse tables that were already built from it instead of building them again.
  • Staging and development environments always run the most up-to-date Cube version, while production follows its update channel. If the newer version generates different SQL for a pre-aggregation, a branch builds its own tables even though the definition is unchanged.
  • Staging and development environments have no scheduled refresh. Their pre-aggregations are built when first queried or when you use Build all or Build Selected on the Pre-Aggregations page.
Building pre-aggregations from a staging or development environment also runs the regular cleanup of unused tables in the shared schema. It can remove older production tables that are no longer in use. The production environment rebuilds them on its next scheduled refresh; until then, queries served by those pre-aggregations can return incomplete results or fail. Avoid building large partitioned pre-aggregations from a branch. To test pre-aggregation builds safely, use a separate deployment on a different Git branch.

​
API endpoints

Each environment provides its own set of API endpoints. You can access them on the Overview page of your deployment or by navigating to the Integrations page and clicking API credentials.