Databricks MLOps Stacks: a bundle template that scaffolds CI/CD for ML projects

The gap MLOps Stacks fills for Databricks teams

Most ML projects do not start badly because of modelling. They start badly because the first commit is a notebook, the first deployment is a manual job run from the workspace UI, and by the time anyone writes tests the training script has grown into something nobody wants to refactor. MLOps Stacks targets exactly that moment: the beginning of a project.

It is aimed at two roles with different entry points. Data scientists get an example project structure with training and batch inference code, Python modules that are unit tested, and notebooks. Ops engineers get the same project with CI/CD and ML resource management already wired up, so the transition to production does not require a rewrite. The README frames the split directly: data scientists iterate on ML code, ops engineers set up CI/CD and resource management.

The project is in public preview, and the README says so in its first note. Databricks asset bundles and bundle templates are also in public preview. That is worth weighing before you make it the foundation of a long-lived platform.

Three components: ML code, resources as code, and CI/CD

An instantiated project is not one thing. The default stack has three modular components that can be generated together or separately.

The first is the ML code: an example project structure with training and batch inference directories, unit tested Python modules, and notebooks. The second is ML resources as code: training and batch inference jobs defined through Databricks CLI bundles, stored as resource files in the project rather than clicked together in the workspace UI. The README's stated reason is governance. Changing an instance type for automated model retraining becomes a pull request instead of an ad hoc UI edit. The third component is CI/CD, delivered as either GitHub Actions or Azure DevOps workflows that test and deploy both the code and the resources.

The pipeline assumes three execution environments: dev, staging, and prod. Each maps to a Databricks workspace. A pull request triggers unit tests and integration tests in an isolated staging workspace. Merging into main updates the staging training and batch inference jobs to run the latest code. Promotion to production happens by cutting a release branch as part of a scheduled release process. Pipeline.md holds the detailed diagrams; the README only summarises the loop.

Installing MLOps Stacks and generating a first project

Two prerequisites are listed: Python 3.8 or later, and Databricks CLI at version 0.236.0 or higher. The CLI carries the bundle template machinery, so there is no separate package to install for MLOps Stacks itself. Follow the Databricks CLI installation instructions first, then run the init command.

databricks bundle init mlops-stacks

That command prompts for parameters rather than taking them all as flags. The first prompt that matters is input_setup_cicd_and_project, which takes one of three values. CICD_and_Project is the default and generates both. Project_Only generates the ML project without CI/CD, which the README describes as easiest for data scientists getting started. CICD_Only generates the workflows only, which the README suggests for monorepo setups or for adding CI/CD to a project that already exists.

After the prompts finish you have a directory containing the project code, a resources folder with the job definitions, and either a .github or .azure directory depending on the provider you selected. The README does not document a rollback or an uninstall path for a generated project.

Where the template stops helping

The generated project assumes a specific operating model, and the seams show where that model does not hold.

The dev, staging, and prod split is not created for you. The template writes workflows and job resources that expect those environments to exist as separate Databricks workspaces. If your organisation runs a single workspace, the promotion model in the README does not map onto your setup, and you will be editing the generated workflows before they are useful. The README does not describe how to collapse the three environments into one.

CI/CD is a binary choice between GitHub Actions and Azure DevOps. GitLab, Bitbucket, Jenkins, and self-hosted runners are not mentioned. If your Git host is not one of those two, the CI/CD component is a starting point you rewrite rather than a component you use.

The release process is manual by design. Merging into main promotes to staging automatically, but production requires a human to cut a release branch. Teams expecting continuous deployment to production will find an extra step they have to automate themselves.

Finally, the whole thing is Databricks-specific. The resource definitions are Databricks CLI bundles, the jobs run in Databricks workspaces, and the example code targets that platform. There is no portable core.

How it differs from Kubeflow Pipelines and plain cookiecutters

The closest comparison is Kubeflow Pipelines, which also gives you a way to define ML workflows as code and run them. The difference is where the definitions live and what executes them. Kubeflow Pipelines compiles pipeline definitions into artefacts that run on Kubernetes, and you operate the cluster, the pipeline service, and the storage. MLOps Stacks defines jobs as Databricks bundle resources and hands execution to Databricks workspaces you already pay for. That removes a large operational surface, and it also removes the option of running the same pipeline somewhere else.

The other comparison is a plain project cookiecutter. A generic ML cookiecutter gives you a directory layout and maybe a Makefile. MLOps Stacks gives you a layout plus job resource definitions plus CI/CD workflows plus the promotion model connecting them. The cost of that extra scope is that the template carries opinions about your environments and your Git host, and those opinions are harder to remove than a directory convention.

A third option is doing nothing and defining jobs in the workspace UI. The README's argument against that is auditability: resource changes made by hand are not reviewed, and the template's premise is that they should go through pull requests.

Maintenance, versioning, and the Apache-2.0 licence

The repository is not archived, and the last push was on 2026-09-08. The release history is uneven rather than steady: v0.3 in March 2024, v0.4 in June 2024, then a gap to v0.5 in July 2026. Anyone planning around this template should read that cadence as sparse, and should expect to maintain generated projects themselves between releases rather than waiting for upstream fixes.

Upgrade cost is a real consideration because the template generates files into your repository rather than installing a dependency. There is no package version to bump. Moving to a newer template means re-running init and reconciling the output against your modified project, or reading the diff between template versions by hand. The README does not document an upgrade path for existing projects.

The licence is Apache-2.0, which permits commercial use and modification and includes a patent grant. That applies to the template code. It does not say anything about the terms of the Databricks platform your generated project runs on, which is a separate commercial relationship. Nothing here is legal advice; check the licence file and your Databricks agreement.

Editorial conclusion

Adopt it if your team already runs Databricks workspaces and GitHub or Azure DevOps and wants job definitions and CI/CD generated rather than hand-written. Do not adopt it if you are not on Databricks, or if your data scientists only work in notebooks and will not touch a repository. Verify first that your Databricks CLI is at least v0.236.0, which CI/CD provider your template scaffolds, and whether your workspaces are already set up for the dev, staging and prod split the pipeline assumes.

Frequently asked questions

Official sources

1. databricks/mlops-stacks on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases