Deployments
Target environments that map your logical datasets to physical warehouse tables — production, development, staging, or any custom environment.
When to use it: When you need the same semantic model to run against different warehouses or schemas (e.g. prod data vs dev data), or when promoting changes from staging to production.
Where to find it: Lumen → Physical Layer → Deployments.
Who can use it: Luminary only.
A deployment is a target environment. Each deployment has its own complete set of dataset mappings that say: "In this environment, the orders dataset points to this connection and this table."
Every workspace has exactly one default deployment. Discover, Mosaics, Orion, and all end-user analytics always run through the default deployment.
Why deployments exist
The most common use case is separating production and development data:
| Without deployments | With deployments |
|---|---|
| One set of nodes pointing to prod tables | Same nodes; different mappings per deployment |
| Testing model changes risks production | Dev deployment points to dev tables |
| Promoting changes requires table edits | Promote by changing the default deployment |
A single semantic model — same CML, same nodes, same metrics — runs cleanly across all environments.
Deployment schema
Each deployment has:
| Field | Description |
|---|---|
name | Internal identifier, unique per workspace (e.g. prod, dev, staging) |
label | Display name shown in the UI (e.g. Production, Development) |
description | Optional documentation |
is_default | Whether this is the active deployment for end-user queries |
Exactly one deployment per workspace can have is_default = true. Setting a new deployment as default automatically clears the previous default.
Creating a deployment
Open Deployments
Go to Lumen → Physical Layer → Deployments and click New Deployment.
Name the deployment
Set an internal name (used in the API and logs) and a human-readable label shown in the UI. Example: name prod, label Production.
Set as default (optional)
Check Make this the default deployment if you want this environment to become the active one for all queries. Only do this when the deployment has complete mappings ready.
Add mappings
After creating the deployment, go to each dataset and add a mapping for this deployment specifying the connection and physical table. See Dataset Mappings.
Managing the default deployment
The default deployment determines what Discover queries. To promote a new deployment:
Prepare the new deployment
Ensure all datasets that your nodes reference have valid mappings in the target deployment. Run validation on each dataset to check compatibility scores.
Set the new default
Open the deployment and click Set as Default, or edit the deployment and check the is_default box. Celiq atomically clears the old default and sets the new one.
Verify
Open Discover, run a Reveal that uses affected nodes, and confirm the results come from the expected environment. Check the query SQL (visible in the SQL pane) to see which physical table was used.
Switching the default deployment is immediate and affects all users in the workspace. Ensure the new deployment has complete, validated mappings before promoting it. A deployment with missing mappings will cause DATASET_NOT_MAPPED errors in Discover for affected nodes.
Deleting a deployment
Deleting a deployment cascades to delete all of its dataset mappings. The deployment's mosaics are not deleted — they continue to exist but may show errors if they reference datasets that were only mapped in the deleted deployment.
You cannot delete the default deployment. Assign a different deployment as default first.
Deployment vs. connection
A common point of confusion:
| Concept | What it is | Analogy |
|---|---|---|
| Connection | Credentials for a warehouse (host, user, password) | A database driver |
| Deployment | A collection of table mappings for an environment | An environment config file |
A deployment doesn't store credentials — it references connections. One connection can be used across many deployments; one deployment can draw from multiple connections.
Example: A staging deployment might use your Postgres staging connection for most tables, but still reference your Snowflake production connection for a reference table that doesn't have a staging copy.
Mosaic deployment pinning
Each Mosaic can optionally be pinned to a specific deployment rather than using the workspace default. This allows you to build a "staging preview" dashboard alongside your production dashboard without affecting end users.
To pin a Mosaic, open its settings and select a deployment from the Deployment dropdown.
Related pages
- Physical Layer Overview — the full picture
- Datasets — logical table definitions
- Dataset Mappings — wire datasets to tables
- Connections — warehouse credentials