metadata-ingestion/docs/sources/cube/cube_pre.md
The cube module ingests the Cube semantic layer data model into DataHub. Every cube and view is emitted as a dataset, with its measures and dimensions modelled as schema fields, organised under a container that represents the Cube deployment. The module works against both Cube Core and Cube Cloud.
Set deployment_type to match your Cube installation:
CORE — a self-hosted Cube Core instance. Metadata is read from the /v1/meta REST endpoint.CLOUD — a Cube Cloud deployment. When use_metadata_api is enabled, the connector reads from the Metadata API, which additionally exposes lineage to upstream warehouse tables. If the supplied token lacks the required scope, the connector automatically falls back to /v1/meta.The connector authenticates with a token sent in the Authorization header.
CUBEJS_API_SECRET. See Security context./v1/meta): copy a token from the deployment's Playground → API tab, or sign one with the deployment's API secret.api_url is the base URL of the REST API, including the base path (defaults to /cubejs-api):
http://localhost:4000/cubejs-apihttps://<deployment>.cubecloud.dev/cubejs-apiTo connect cubes to the warehouse tables they read from, set warehouse_platform (e.g. snowflake, bigquery, postgres) and, if your existing datasets use them, warehouse_platform_instance and warehouse_env. On Cube Cloud with the Metadata API enabled, the warehouse platform and database are auto-detected from the deployment's data sources. On Cube Core, set parse_sql_for_lineage to derive table lineage from each cube's SQL definition (requires warehouse_platform).
Note that cubes marked public: false are not returned by the /v1/meta endpoint, so views that reference them will still produce lineage edges to those cubes even though the cubes themselves are not ingested.