One CLI for your whole data stack.
OpenDOPS gives you the dops CLI to standardize
project structure and automation across your data stack — scaffold or adopt
projects, isolate sandbox deployments per branch, and ship CI that calls native tools
directly. One consistent workflow for every tool.
Databricks (bundles + notebooks) and dbt ship today — Airflow and
Snowflake are on the way.
$ dops dbt init analytics ✓ Initialized dbt project analytics $ dops adopt ./legacy-platform ✓ Adopted monorepo legacy-platform + 3 bundles $ dops list bundle customer-events-bronze dbx dab notebook analytics-notebooks dbx notebook dbt analytics dbt $ dops check --all ✓ All 3 projects passed▋
The core principle
OpenDOPS owns structure. Your native tools own execution.
It scaffolds, validates, and standardizes project structure across your data stack — and never replaces your native CLIs, provisions infrastructure, manages Terraform, or stores secrets.
Built for the modern data engineering stack
Everything in one CLI
From empty repo to production
The same capabilities for every domain — structure, metadata, checks, and CI generated for you. Available today across Databricks (bundles + notebooks) and dbt.
Project scaffolding
Generate standardized repos and projects in one command — Databricks bundle monorepos, notebook projects, and dbt projects today, more domains next.
Adopt existing projects
Already building? dops adopt brings an existing dbt or Databricks project under management — inferring metadata from what's on disk, without moving or rewriting a single file.
Conflict-aware upgrades
Pull blueprint improvements into existing projects with dops upgrade. A per-project lock classifies every file as safe-update or conflict, so your local edits are never clobbered.
Branch-isolated sandboxes
A runtime DEV_<branch>_ prefix isolates feature-branch deployments — applied to resource names, workspace paths, or dbt schemas, never committed to config.
Provenance & versioning
Every deploy is stamped with its version and git commit — as resource tags, a dbt query-comment, or a workspace marker — so you always know what's running where.
Generated CI/CD
Ready-made GitHub Actions that call your native CLI directly: validate, sandbox deploy & cleanup, and dev / staging / prod promotion.
Structural checks
check and doctor verify conventions, targets, and metadata with clear, actionable diagnostics — and never call out to your data platform.
Policy & governance
Encode org standards once in .dops/policy.yaml — required owner, allowed blueprints, targets, naming — and check enforces them everywhere, with a pre-commit hook.
Changed-project detection
Map a git diff to exactly the affected projects — with --format github-json for CI matrices.
Multi-domain by design
One CLI for your whole data stack
OpenDOPS is a framework for standardizing data engineering project structure across tools —
not a single-vendor wrapper. Databricks (bundles + notebooks) and
dbt ship today; more domains are on the roadmap, each under its own
dops namespace.
Databricks DAB
dops dbx dab
Declarative Automation Bundle monorepos — bundles, targets, sandbox prefixes, and CI.
Databricks Notebooks
dops dbx notebook
Non-DAB notebook/workspace projects deployed with native databricks sync — branch-isolated by workspace folder.
dbt
dops dbt
Standardized dbt projects — staging/marts models, sources, seeds, tests, env targets, and CI. Branch-isolated sandbox schemas; run with the dbt CLI.
Apache Airflow
dops airflow
Opinionated DAG project layout, shared operators, and deployment workflows.
Snowflake
dops snowflake
Repeatable warehouse, pipeline, and migration scaffolding with branch-safe deploys.
Want a domain sooner? Open an issue — the blueprint model is built to extend.
How it works
The same workflow, every domain
Whether you're working in Databricks bundles, notebooks, or dbt, the steps are identical. These context-aware commands auto-detect the project you're in — no domain prefix required.
- 01
Scaffold — or adopt
Generate a standardized project in one command, or adopt an existing dbt / Databricks one. Either way it lands in the same .dops registry.
$dops dbt init analytics · dops adopt ./existing-repo - 02
Check conventions
Validate structure and metadata across every project in the repo — before you ever touch a live system.
$dops check --all - 03
Print native deploy commands
Get the exact native commands — databricks bundle, databricks sync, or dbt — with a branch-derived sandbox.
$dops commands --target sandbox --branch feature/DOPS-123 - 04
Upgrade safely
Pull blueprint improvements into existing projects later, without clobbering your local edits.
$dops upgrade
Skip the scaffolding. Adopt an existing dbt or Databricks project — OpenDOPS infers the metadata and leaves every one of your files untouched.
dops adopt --owner data-platformDeployment model
Isolated sandboxes. Canonical releases.
The same stable targets for everyone, in every domain. Branch identity is supplied at runtime — never committed, never promoted. (Shown here with Databricks bundles.)
Feature-branch sandbox
stable target · runtime prefix
Deploy to the stable sandbox target with a
deterministic prefix derived from the branch name.
$ databricks bundle deploy -t sandbox \ --var="resource_prefix=DEV_feature-dops-123_" # creates / updates DEV_feature-dops-123_customer-events-bronze-job
Official targets
dev · staging · prod
Promote by deploying merged code to an official target. Empty prefix, canonical resource names — no branch, user, or ticket baggage.
$ databricks bundle deploy -t dev # creates / updates customer-events-bronze-job
Same isolation model, mapped to each domain's native unit:
Ship standardized data engineering projects.
Install the dops CLI and scaffold your first
standardized project in under a minute.