GeezerVison

Deployments are top-level entities in Cube Cloud. They include the source code, configuration, allocated resources, API endpoints and essentially do all the heavy lifting, running workloads and fulfilling requests.

​

List of deployments

Each account in Cube can have multiple deployments. To see the list of deployments, click Admin at the bottom of the sidebar, then click Deployments. With more than one deployment, an admin can pin one as the account-wide default from its row’s ⋯ menu (Set as default / Remove as default). This is what a user lands on when they open Cube without a deployment in the URL and haven’t set their own default deployment or previously switched deployments.

​

Creating a new deployment

Creating a new deployment is an essential prerequisite to running a Cube project in Cube Cloud. After you’ve created your Cube Cloud account, click Create deployment in the top-right corner of your list of deployments to jump into the wizard. Watch the following video for guidance on the rest of the steps: All deployments within a Cube Cloud account should have unique names.

​

Demo deployments

After you’ve created your Cube Cloud account and proceeded to create a new deployment, you would be prompted to set up a connection to your data source. If, for any reason, you’re not ready or unable to connect your staging or production data source at the moment, you can click Create a demo deployment in the yellow box: Shortly, Cube Cloud will create and pre-configure a new deployment in your account. You will see it as Demo deployment in the list of deployments. This new deployment will be:

• Configured to use DuckDB as the data source.
• Provided with a sample data model backed with CSV files in a public S3 bucket.
• Provided with an example of dynamic data modeling and programmatic configuration options.

Watch the following video to for a step-by-step walkthrough: Exploring the demo deployment is a great way to understand how Cube works. Use the data model editor to review the data model and make sure to run a few queries in Playground.

​

Deployment status

The Status page of each deployment provides a high-level summary of its components and state. To open it, click Monitoring in the sidebar, then click Status. The page has three sections:

• Integrations shows the number of API requests in the last 24 hours and the status of each API. Click API credentials to get the API endpoints and connection instructions.
• Resources & logs shows the resources allocated in line with the deployment type, with links to their logs.
• Activity log shows the most recent events, such as builds and changes to the deployment settings. Click View all to see the full log.

​

Activity log

Each build is shown as Build #N with a status icon, the user who triggered it, and the time when it started. The icon shows whether the build is scheduled or in progress, warming up pre-aggregations, successful, failed, or cancelled because a newer build replaced it. Click a build to see its logs. A build of a deployment connected to a Git repository also shows the first 8 characters of the commit SHA and the commit message. To find out which commit your deployment runs, check the build number in the header of the Resources & logs section, then find that build in the activity log. A build deployed with the Cube CLI shows Deployed using CLI instead of a commit.

​

Deployment settings

You can manage various settings of a deployment, such as environment variables, by navigating to the Settings page of the deployment.

​

Environment variables

You can configure environment variables by navigating to Settings → Environment variables where you can add, edit, or remove environment variables for your deployment. For convenience, environment variables are split into two lists: ones that relate to the data source configuration and all other variables. Browsing environment variables is reflected in the Audit Log.

​

Cube version

Each environment within a Cube Cloud deployment runs a specific version of Cube that depends on the environment type and the selected update channel.

​

Current version

You can check the current version of Cube that your deployment runs by navigating to Settings → General and looking at the Version field.

​

Update channels

Cube Cloud provides two update channels:

• LTS channel for infrequent long-term support releases with critical fixes.
• Regular channel for regular releases, which occur more frequently and contain both fixes and new features.

You can view or change the update channel by navigating to Settings → General and using the Update channel field: You can select a specific version in the Version drop-down. Only versions that have been used by a deployment during the last 6 months are available in the list. There’s an Auto-upgrade option to automatically upgrade to new patch versions, which is available for both update channels. When it’s turned on, an upgrade will occur if a new patch version is available in the selected channel. To trigger an upgrade, deploy a new build to the production environment or change its settings, e.g., by updating environment variables of the Cube Cloud deployment. Generally, it’s recommended to use the regular channel to get the latest updates. You can pin the version to a specific one by turning the Auto-upgrade toggle off. If you choose to pin the version, make sure to upgrade periodically, especially when the next minor version is released. If you use the LTS channel, make sure to upgrade to the latest LTS version every few months.

​

Changing the version

When you select a different version and save the settings, Cube redeploys the current build on the new version. It does not start a new build. The change is shown in the activity log as Cube version update, with the previous and the new version. The time of this entry is when the version was changed, not when the deployment started to serve requests on the new version. On Dedicated and Multi-cluster deployments, instances that run the previous version keep serving API requests until instances that run the new version are ready.

​

Resource consumption

Cube Cloud deployments only consume resources when they are needed to run workloads:

• For the production environment, resources are always consumed unless a deployment is suspended.
• For any other environment, 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. After a period of inactivity, Cube Store workers are deallocated.

Please refer to pricing to learn how many CCUs each resource consumes.