Configuration options

Following configuration options can be defined either using Python, in a cube.py file, or using JavaScript, in a cube.js file.

Data model

schema_path

Path to data model files.

Overrides CUBEJS_SCHEMA_PATH. The default value is model.

Use repositoryFactory for multitenancy or when a more flexible setup is needed.

context_to_app_id

It's a multitenancy option.

context_to_app_id is a function to determine an app id which is used as caching key for various in-memory structures like data model compilation results, etc.

Called on each request.

repository_factory

This option allows to customize the repository for Cube data model files. It is a function, which accepts a context object and can dynamically provide data model files. Learn more about it in multitenancy.

Called only once per app_id.

You can use convenient file_repository implementation to read files from a specified path:

You can also provide file contents directly, e.g., after fetching them from a remote storage or via an API:

schema_version

schema_version can be used to tell Cube that the data model should be recompiled in case it depends on dynamic definitions fetched from some external database or API.

This method is called on each request however RequestContext parameter is reused per application ID as determined by context_to_app_id. If the returned string is different, the data model will be recompiled. It can be used in both multi-tenant and single tenant environments.

compiler_cache_size

Maximum number of compiled data models to persist with in-memory cache. Defaults to 250, but optimum value will depend on deployed environment. When the max is reached, will start dropping the least recently used data models from the cache.

max_compiler_cache_keep_alive

Maximum length of time in ms to keep compiled data models in memory. Default keeps data models in memory indefinitely.

update_compiler_cache_keep_alive

Setting update_compiler_cache_keep_alive to True keeps frequently used data models in memory by reseting their max_compiler_cache_keep_alive every time they are accessed.

allow_js_duplicate_props_in_schema

Boolean to enable or disable a check duplicate property names in all objects of a data model. The default value is false, and it is means the compiler would use the additional transpiler for check duplicates.

Query cache & queue

cache_and_queue_driver

The cache and queue driver to use for the Cube deployment. Defaults to memory in development, cubestore in production.

context_to_orchestrator_id

context_to_orchestrator_id is a function used to determine a caching key for the query orchestrator instance. The query orchestrator holds database connections, execution queues, pre-aggregation table caches. By default, the same instance is used for all tenants; override this property in situations where each tenant requires their own Query Orchestrator.

Called on each request.

driver_factory

A function to provide a custom configuration for the data source driver. Can be asynchronous.

Called once per data_source for every orchestrator id.

Should be used to configure data source connections dynamically in multitenancy.

Not recommended to be used when multiple data sources can be configured statically. Use CUBEJS_DATASOURCES and decorated environment variables in that case.

In Python, should return a dictionary; in JavaScript, should return an object. It should contain the type element corresponding to data source type and other options that will be passed to a data source driver. You can lookup supported options in the drivers' source code (opens in a new tab).

In JavaScript, custom driver implementations can also be loaded:

const VeryCustomDriver = require('cube-custom-driver');
 
module.exports = {
  driverFactory: ({ securityContext, dataSource }) => {
    return new VeryCustomDriver({
      /* options */
    })
  }
};

orchestrator_options

You can pass this object to set advanced options for the query orchestrator.

queryCacheOptions are used while querying database tables, while preAggregationsOptions settings are used to query pre-aggregated tables.

Timeout and interval options' values are in seconds.

Pre-aggregations

pre_aggregations_schema

Schema name to use for storing pre-aggregations. Either string or function could be passed. Providing a function allows to dynamically set the pre-aggregation schema name depending on the security context.

Defaults to dev_pre_aggregations in development mode and prod_pre_aggregations in production.

Can be also set via environment variable CUBEJS_PRE_AGGREGATIONS_SCHEMA.

Called once per app_id.

scheduled_refresh_timer

Cube enables background refresh by default using the CUBEJS_REFRESH_WORKER environment variable.

Learn more about scheduled refreshes here.

Best practice is to run scheduled_refresh_timer in a separate worker Cube instance. For Serverless deployments, REST API should be used instead.

You may also need to configure scheduledRefreshTimeZones and scheduledRefreshContexts.

scheduled_refresh_time_zones

All time-based calculations performed within Cube are timezone-aware. Using this property you can specify multiple timezones in TZ Database Name (opens in a new tab) format e.g. America/Los_Angeles. The default value is UTC.

You can define one or multiple timezones:

This configuration option can be also set using the CUBEJS_SCHEDULED_REFRESH_TIMEZONES environment variable. You can set a comma-separated list of timezones to refresh in CUBEJS_SCHEDULED_REFRESH_TIMEZONES environment variable. For example:

CUBEJS_SCHEDULED_REFRESH_TIMEZONES=America/Los_Angeles,UTC

scheduled_refresh_contexts

When trying to configure scheduled refreshes for pre-aggregations that use the securityContext inside context_to_app_id or context_to_orchestrator_id, you must also set up scheduled_refresh_contexts. This will allow Cube to generate the necessary security contexts prior to running the scheduled refreshes. Can be asynchronous.

Querying

query_rewrite

This is a security hook to check your query just before it gets processed. You can use this very generic API to implement any type of custom security checks your app needs and rewrite input query accordingly.

Called on each request.

For example, you can use query_rewrite to add row-level security filter, if needed:

allow_ungrouped_without_primary_key

Setting allow_ungrouped_without_primary_key to True disables primary key inclusion check for ungrouped queries.

APIs

base_path

The base path for the REST API.

The default value is /cubejs-api.

http.cors

CORS settings for the Cube REST API can be configured by providing an object with options from here (opens in a new tab):

web_sockets_base_path

The base path for the WebSocket server.

The default value is / (the root path).

process_subscriptions_interval

This property controls how often WebSocket client subscriptions are refreshed. Defaults to 5000.

context_to_api_scopes

This function is used to select accessible API scopes and effectively allow or disallow access to REST API endpoints, based on the security context. Can be asynchronous.

Security context is provided as the first argument. An array of scopes that was set via CUBEJS_DEFAULT_API_SCOPES is provided as the second argument.

Called on each request.

extend_context

Option to extend the RequestContext with custom values. This method is called on each request. Can be asynchronous.

The function should return an object which gets appended to the RequestContext. Make sure to register your value using context_to_app_id to use cache context for all possible values that your extendContext object key can have.

You can use the custom value from extend context in your data model like this:

const { activeOrganization } = COMPILE_CONTEXT;
 
cube(`Users`, {
  sql: `SELECT * FROM users where organization_id=${activeOrganization}`,
});

check_auth

Used in both REST and WebSockets API. Can be asynchronous.

Default implementation parses JSON Web Token (JWT) (opens in a new tab) in Authorization header and sets payload to securityContext if it's verified. More information on how to generate these tokens is here.

You can set securityContext = userContextObj inside the middleware if you want to customize SECURITY_CONTEXT.

Called on each request.

You can use empty check_auth function to disable built-in security or raise an exception to fail the authentication check.

jwt

  jwt: {
    jwkUrl?: ((payload: any) => string) | string;
    key?: string;
    algorithms?: string[];
    issuer?: string[];
    audience?: string;
    subject?: string;
    claimsNamespace?: string;
  };

• jwkUrl — the URL from which JSON Web Key Sets (JWKS) can be retrieved. Can also be set using CUBEJS_JWK_URL.
• key — a JSON string that represents a cryptographic key. Similar to API_SECRET. Can also be set using CUBEJS_JWT_KEY.
• algorithms — any supported algorithm for decoding JWTs (opens in a new tab). Can also be set using CUBEJS_JWT_ALGS.
• issuer — an issuer value which will be used to enforce the iss claim from inbound JWTs (opens in a new tab). Can also be set using CUBEJS_JWT_ISSUER.
• audience — an audience value which will be used to enforce the aud claim from inbound JWTs (opens in a new tab). Can also be set using CUBEJS_JWT_AUDIENCE.
• subject — a subject value which will be used to enforce the sub claim from inbound JWTs (opens in a new tab). Can also be set using CUBEJS_JWT_SUBJECT.
• claimsNamespace — a namespace within the decoded JWT under which any custom claims can be found. Can also be set using CUBEJS_JWT_CLAIMS_NAMESPACE.

check_sql_auth

Used in SQL API, and can be asynchronous. Default implementation verifies user name and password from environment variables: CUBEJS_SQL_USER, CUBEJS_SQL_PASSWORD, but in development mode it ignores validation.

Called on each new connection to Cube SQL API, on change user by SET USER or __user field, every CUBESQL_AUTH_EXPIRE_SECS.

For example, you can use check_sql_auth to validate username and password. password argument is provided only when new connections are established. check_sql_auth implementation should gracefully handle missing password field to handle change user and re-authentication flows. check_sql_auth should always return password as it used for validation of password provided by user. If clear text password can't be obtained, best practice is to return password provided as an argument after password validation. Only security context is used for change user and re-authentication flows so returned password isn't checked in this case.

can_switch_sql_user

Used in SQL API, and can asynchronous. Default implementation depends on CUBEJS_SQL_SUPERUSER and return true when it's equal to session's user.

Called on each change request from Cube SQL API.

For example, you can use can_switch_sql_user to define your custom logic:

Utility

logger

A function to server as a custom logger.

Accepts the following arguments:

• message: the message to be logged
• params: additional parameters

telemetry

Cube collects high-level anonymous usage statistics for servers started in development mode. It doesn't track any credentials, data model contents or queries issued. This statistics is used solely for the purpose of constant cube.js improvement.

You can opt out of it any time by setting telemetry option to False or, alternatively, by setting CUBEJS_TELEMETRY environment variable to false.

Deprecated

initApp

This function allows you to extend the Cube API server with custom Express middleware. This is especially useful for adding monitoring and observability solutions.

const myCustomMiddleware = (req, res, next) => {
  req.foo = "bar";
  next();
};
 
module.exports = {
  initApp: (app) => {
    app.use(myCustomMiddleware);
  },
};

dbType

Data source type. Called only once per appId.

module.exports = {
  // string
  dbType: 'snowflake',
 
  // function
  dbType: ({ securityContext }) => 'databricks',
};

Either string or function could be passed. Providing a Function allows to dynamically select a database type depending on the security context. Usually used for multitenancy.

If not defined, Cube will lookup for environment variable CUBEJS_DB_TYPE to resolve the data source type.