Private beta · join the waitlist

Run dbt in production.
Without running anything.

Managed runs for your dbt projects, with the docs, lineage and the current state of every test on the same screen as the runs. No hopping between a runner and a docs site.

No credit card. Onboarding a few teams a week; the sample project builds in about 20 seconds with no warehouse.

#4808 daily_build Running Production

Steps 0 of 5 passed Scheduled · today 18:45

step 1 of 5 Open run →

How it works

Three steps, the same three you see on Get started

No agents, no cluster to size, no config file to learn. The product walks you through the same checklist this page does.

Install the GitHub App

Pick the repositories auradata may read. It reads code and pull requests and writes check runs; it never pushes to your repo.

✓ Installed on acme · 2 repositories

Add your warehouse

Save a connection once for the workspace and test it. Credentials go to the secret store; only runners ever receive them.

✓ snowflake-prod · test passed

Create a project

Choose the repository, a production schema and a schedule. A CI environment comes with it. Your first run is one click away.

✓ acme-analytics is set up

Git-native

Your Git workflow, already wired up

Pull requests get checked before merge. Merges deploy. Both use the same runner, the same isolation, the same logs.

● Some checks haven’t completed yet

auradata / pr_check Building 5 modified models in pr_1… Details

pr_1 · one schema per pull request, built with state:modified+ deferred to production

✓ Merged into main · 7fd92af

✓ auradata / deploy_on_merge run #4806 · Production · 5 models · 10 tests · 27s Details

The merge commit gets its own check, so the badge on main is the production build, not the PR's.

1 Pull request opened webhook from GitHub
2 Build in pr_1 modified models, deferred
3 Check on the commit green before merge
4 Merge builds production same runner, same logs

Run on pull request pull_request

Turn on one pull-request job and every PR builds into its own schema, pr_<number>: only the modified models and their children, deferred to production state. The result posts back as a check on the commit.

Run on merge merge

A merge into your production branch runs that environment's job at the merge commit, with its own check. Same runner, same logs, same isolation as the PR build.

Environments prod · staging · ci

Each environment maps to one connection and one schema. The CI environment comes with every GitHub project and is not counted against your plan.

A job-level dbt line lets you probe the next dbt version on a copy, without touching production.
Every run records the commit it built, so a red run points at a diff.
Re-run from the failed step, or cancel a run cleanly; the terminal status is always written.

Catalog

Runs and docs on the same platform. No hopping.

Runs are the input, not the product. Each one updates the docs, the lineage and the current state of every test, on the same screen where you read the run.

acme-analytics · Production

Model	Materialization	Last built	Tests
fct_orders	table	4m ago	6 passed
dim_customers	table	4m ago	4 passed · 1 warn
int_order_items	ephemeral	4m ago	2 passed
stg_payments	view	4m ago	1 failed
stg_orders	view	4m ago	3 passed

Docs for all 48 models regenerated on the last production run. Open a model and its columns, SQL, tests and neighbours are right there.

Test	Model	Status	Last checked
accepted_values_payment_method	stg_payments	failed · 2 rows	4m ago
not_null_customers_email	dim_customers	warn · 11 rows	1h ago
unique_orders_order_id	fct_orders	passed	4m ago
relationships_orders_customer	fct_orders	passed	4m ago

The latest result for each of 312 tests, across every run: a partial build that only touched three models cannot overwrite the tests it never ran.

Docs

Generated on every run, read in place

dbt docs generate is a step of your production job. Columns, compiled SQL and descriptions open from the model, next to its runs. No bucket, no static-site job, no stale catalog.

Lineage

Status on the graph, not beside it

One DAG carrying the last build and test health together. Pick a node to see its last build, its tests and everything downstream at risk.

Tests

Latest result per test, not per run

Rolled up across every run, so a partial build cannot mask a failure from the nightly. One row per test, always current, with its 14-day history.

Features

Built around how runs actually fail

Every one of these exists because the alternative is a stuck run and a Slack thread.

Isolated runs

Every run gets its own container with your code and your warehouse credentials. Nothing is shared between tenants.

Re-run from failure

Resume at the failed step instead of rebuilding the DAG. Artifacts are kept for every run.

Cancel that works

A cancelled run closes its warehouse session and writes a terminal status. No zombie runs holding a slot.

Real logs

Full dbt output for every step, kept after the run. Not sampled, not truncated.

Schedules

Cron jobs per environment, with pause and resume. A scheduler that never fires twice for one tick.

Alerts and issues

Failures grouped by signature, so one bad model is one issue. Rules route them to email or a webhook.

How it fits

Your repo on one side.
Your warehouse on the other.

Nothing migrates. auradata pulls the dbt project you have and runs it against the warehouse you already trust.

Your Git repo

yourco/analytics main

dbt_project.yml

models/

staging/stg_customers.sql

marts/fct_revenue.sql

schema.yml

It stays exactly where it is.
No import, no browser IDE.

auradata

auradata runtime + control plane

Schedulescron, on merge or on demand, per job

Run logsevery step, filterable, kept after the run

Observabilitytests, issues, lineage, source freshness

Environmentsproduction, staging and CI, each on its own connection

Teamsroles, teams, invitations, audit log

The runtime, and the record of
everything it runs.

Your warehouse

Snowflake

BigQuery

Databricks

Redshift

Postgres

MotherDuck

Storage and compute stay yours,
on credentials you control.

Positioning

Between a platform team and a platform bill

Running dbt yourself is cheap until the first stuck run at 2am. Here is the honest comparison.

Capability	auradata	dbt Cloud	Run it yourself
Time to first run	Minutes	Minutes	Days
Pull request checks in their own schema	Included	Included	You build it
Re-run from the failed step	Included	Included	You build it
Docs, lineage and test state next to the run	Included	Separate product	You host it
Latest result per test, across runs	Included	Partial	You build it
Probe the next dbt version from one job	Included	No	You build it
Infrastructure to operate	None	None	Yours
Pricing	Compute minutes	Per seat + usage	Cloud bill + engineer time

Pricing

Free while we're in beta

Beta access

3 projects, 4 environments per workspace, 100 compute minutes a month, every feature on this page.
Pricing is announced at general availability; beta teams keep launch rates for 12 months.

FAQ

Questions we get asked first

Which warehouses are supported?

Snowflake, BigQuery, Databricks, Redshift, Postgres and MotherDuck. Connections are saved once per workspace and tested before any environment uses them.

Where does my code actually run?

In a container created for that single run and removed after it: no shared filesystem, no reused credentials between tenants. Runners fetch your repository with a token minted for that run.

How are warehouse credentials stored?

In a managed secret store, encrypted at rest, injected into the run container at start and never written to logs or artifacts. The app itself only ever holds a reference to the secret.

What permissions does the GitHub App need?

Read on repository contents, metadata and pull requests, write on check runs. No access to repositories you did not select, no write access to your code.

Which dbt versions can I use?

dbt 1.9 to 1.12, pinned per project. Each line is supported for 12 months with 90 days notice before it retires, and one job can probe the next line on a copy before you move.

Are pull request schemas cleaned up?

Each PR builds into pr_<number>. Cleanup when the PR closes is on the roadmap; until then the schema stays until you drop it.

Do I need to host dbt docs anywhere?

No. Docs are generated as a step of your production job and read in the product, next to the run that produced them.

What about GitLab or Bitbucket?

GitHub first, deliberately. Others are on the roadmap.

Point it at a repo. See a run.

We're onboarding a small number of teams each week. Or skip the repo: the sample project builds in about 20 seconds with no warehouse.

Run dbt in production.Without running anything.