Production Checklist

Thinking of migrating to the cloud instead? Click here to learn more about migrating a self-hosted installation to Cube Cloud.

This is a checklist for configuring and securing Cube for a production deployment.

Disable Development Mode

When running Cube in production environments, make sure development mode is disabled both on API Instances and Refresh Worker. Running Cube in development mode in a production environment can lead to security vulnerabilities. You can read more on the differences between production and development mode here.

Development mode is disabled by default.

# Set this to false or leave unset to disable development mode
CUBEJS_DEV_MODE=false

Set up Refresh Worker

To refresh in-memory cache and pre-aggregations in the background, we recommend running a separate Cube Refresh Worker instance. This allows your Cube API Instance to continue to serve requests with high availability.

# Set to true so a Cube instance acts as a refresh worker
CUBEJS_REFRESH_WORKER=true

Set up Cube Store

While Cube can operate with in-memory cache and queue storage, there're multiple parts of Cube which require Cube Store in production mode. Replicating Cube instances without Cube Store can lead to source database degraded performance, various race conditions and cached data inconsistencies.

Cube Store manages in-memory cache, queue and pre-aggregations for Cube. Follow the instructions here to set it up.

Depending on your database, Cube may need to "stage" pre-aggregations inside your database first before ingesting them into Cube Store. In this case, Cube will require write access to the prod_pre_aggregations schema inside your database. The schema name can be modified by the CUBEJS_PRE_AGGREGATIONS_SCHEMA environment variable; see the Environment Variables reference for more details.

You may consider enabling an export bucket which allows Cube to build large pre-aggregations in a much faster manner. It is currently supported for BigQuery, Redshift and Snowflake. Check the relevant documentation for your configured database to set it up.

Secure the deployment

If you're using JWTs, you can configure Cube to correctly decode them and inject their contents into the Security Context. Add your authentication provider's configuration under the jwt property of your cube.js configuration file, or if using environment variables, see CUBEJS_JWK_*, CUBEJS_JWT_* in the Environment Variables reference.

Set up health checks

Cube provides Kubernetes-API compatible health check (or probe) endpoints that indicate the status of the deployment. Configure your monitoring service of choice to use the /readyz and /livez API endpoints so you can check on the Cube deployment's health and be alerted to any issues.

Did you find this page useful?