qyra deploy pushes your dbt project to Qyra.

Once you've made updates to your dbt project and you're ready to make those changes available in your Qyra production project, you have a few options for deploying from the CLI or the Qyra UI. This guide will walk you through how it works, when to use each option, and what to keep in mind for a safe and scalable workflow.

Before you deploy: A quick word of caution

For a safer, scalable approach to deploying and previewing changes, use CI/CD. This allows you to:

• Spin up Qyra preview environments for each PR

• Deploy production changes consistently using shared, secure credentials

• Avoid accidentally pointing to the wrong target in your local profile

Check out our guide to setting up CI/CD workflow

Option 1: Deploy via the CLI

Basic usage:

git checkout main # checkout main or master - or whatever your production branch name is where you've merged your changes
git pull
qyra deploy # --target prod. If you use developer profiles in your dbt project, you might need this flag. See below.

By default, this will:

• Use your local dbt profile for the connection

• Push the current state of your local dbt project files (including uncommitted changes or code from your active branch) to the authenticated Qyra project

• Trigger a re-compile and refresh of your Qyra project

If your dbt project uses different profiles or targets for dev and prod, you can specify which profile to use:

qyra deploy --profile prod

Use strict compilation

Qyra uses partial compilation by default. Field, join, and set-validation failures that can be isolated are reported as warnings so the rest of the explore stays usable; failures that cannot be isolated can still produce errors.

Add --no-partial-compilation to report the failures that partial compilation would otherwise isolate as errors instead. It doesn't promote unrelated, non-blocking warnings — other generic compilation warnings stay non-blocking.

If your project uses physical column references such as ${TABLE}.order_id, add --validate-warehouse-columns to check supported unquoted references with warehouse queries that return no rows. It's opt-in because it sends those queries; whether your warehouse scans or bills for them is warehouse-dependent, and the check needs warehouse credentials and the warehouse catalog. Warehouse-column errors are reported whether partial compilation is on or off.

See the CLI compilation options for the supported reference syntax and every skip condition.

For the strictest deploy, combine both flags:

qyra deploy --no-partial-compilation --validate-warehouse-columns

Do not combine --ignore-errors with this strict CI pattern — --ignore-errors lets a deployment continue after compilation errors, which defeats the check.

Option 2: Safely refresh metadata using qyra refresh

If you only need to refresh your Qyra project to reflect upstream dbt changes (like updated models or docs), but don’t want to deploy your local dbt setup, you can use:

qyra refresh

Unlike deploy, this:

• Uses the saved dbt credentials from Qyra, not your local profile

• Simply re-runs the metadata sync and model parsing

• Makes it safe to trigger from anywhere without risk of pointing to the wrong target

You can also do this directly from the Qyra UI:

Go to your project → "Manage project" → Refresh dbt. This gives the same result as running qyra refresh.