Deploy a dbt project to Remote Execution Agents
Airflow 3
This feature is only available for Airflow 3.x Deployments.Remote Execution Agents run tasks in your own Kubernetes infrastructure. Because Remote Execution mode doesn’t support astro dbt deploy, you must make your dbt project files available to agents through other methods.
This document covers two approaches for deploying dbt code to Remote Execution Agents, ordered by Astronomer’s recommendation.
Prerequisites
- A Remote Execution Deployment with at least one registered agent.
- A secrets backend and XCom backend configured for your agents.
- A dbt project in a Git repository.
- Cosmos installed in your agent client image for orchestrating dbt models.
Option 1: Include the dbt project as a Git submodule (recommended)
Use Git submodules to include an external dbt project repository inside your Dag repository. This approach keeps your dbt and Airflow code in separate repositories while combining them at deploy time.
This is the recommended approach because it:
- Preserves separation of ownership between dbt and Airflow teams.
- Pins the dbt project to a specific commit, giving you control over which version of dbt code runs.
- Works with
GitDagBundlefor automatic Dag versioning.
How it works
Your Dag repository includes the dbt project as a Git submodule. When agents fetch the Dag bundle from Git, the submodule contents are fetched alongside your Dags. Cosmos then reads the dbt project from the submodule folder to orchestrate dbt models as Airflow tasks.
Configure the Dag repository
Add the dbt project as a submodule
From your Dag repository root, run:
For example, to add a dbt project called jaffle-shop:
This creates a .gitmodules file and clones the dbt repository into the dbt/jaffle-shop folder.
Create a Cosmos Dag
Create a Dag that uses Cosmos to orchestrate the dbt project. Set the dbt_project_path to reference the submodule location within the Dag bundle:
The exact path depends on your GitDagBundle configuration. If your bundle uses a subdir parameter, adjust the path accordingly.
Configure agents to fetch submodules
By default, GitDagBundle does not recursively fetch Git submodules. You must configure the git_conn_id connection to include submodule support and ensure the agent can authenticate to the submodule repository.
If the dbt submodule repository uses the same authentication as the Dag repository, configure the Dag bundle with the same git_conn_id. If the submodule is in a public repository, no additional authentication is required.
For private submodule repositories that require separate credentials, configure an additional Git connection in your secrets backend or values.yaml.
Update the dbt submodule
When the dbt team pushes new changes, update the submodule reference in your Dag repository:
Agents pick up the change on the next GitDagBundle refresh cycle.
For more information about working with Git submodules in an Astro context, see Use Git submodules with an Astro project.
Option 2: Include dbt code in the agent client image
Build the dbt project directly into your custom agent client image. This approach works well when dbt code changes infrequently and you want a self-contained image.
This approach requires rebuilding and redeploying the agent image every time dbt code changes. For teams that update dbt models frequently, consider Option 1 instead.