Databricks MLOps Stacks: a bundle template that ships CI/CD with the project
This repo provides a customizable stack for starting new ML projects on Databricks that follow production best-practices out of the box.
At a glance
- What is it?
- MLOps Stacks is a Databricks asset bundle template that scaffolds an ML project, its job resources and its CI/CD workflows in one command. It is built for teams already on Databricks; the value and the lock-in both come from that assumption.
- Who is it for?
- Adopt it if your ML work already runs on Databricks workspaces and you want the training job, the batch inference job and the pipeline that deploys them to arrive together, defined as databricks bundle resources. Do not adopt it if your training or serving stack lives outside Databricks, or if you cannot commit to running databricks bundle init and maintaining the generated repository yourself.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 8 days ago.
- What is it written in?
- Mainly Go Template, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 16, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap MLOps Stacks fills between a notebook and a deployed job
A data scientist can prototype a model in a Databricks notebook in an afternoon. Turning that notebook into something with unit tests, a scheduled training job, a batch inference job and a release process is a separate project, and it is usually the one that stalls. MLOps Stacks exists to collapse that second project into a single scaffolding command. The README describes the repository as a customizable stack for starting new ML projects on Databricks that follow production best-practices out of the box, and the intended division of labour is explicit: data scientists iterate on ML code while ops engineers set up CI/CD and resource management, with what the README calls an easy transition to production. The audience is therefore narrow and specific. It is teams whose training and inference already run on Databricks and who want the surrounding automation generated rather than hand-written. If your model trains on a Kubernetes cluster and only reads from Databricks, the generated resources will not match your topology.
Three modular components and how they connect
The default stack ships three components that are meant to be adopted together. The first is ML Code: an example project structure with training and batch inference directories, unit tested Python modules and notebooks, so that the code is already factored into importable modules rather than living only inside notebook cells. The second is ML Resources as Code: training and batch inference jobs defined through databricks CLI bundles, stored as YAML templates such as model-workflow-resource.yml.tmpl and batch-inference-workflow-resource.yml.tmpl under the resources directory. The third is CI/CD, generated as either GitHub Actions workflows under .github or Azure DevOps workflows under .azure. The data flow the README describes runs across three workspace tiers it calls dev, staging and prod. 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 the latest code. Promoting to production happens through a release branch cut as part of a scheduled release process. The mechanism that makes the resource layer work is the bundle: the jobs are declared in files, so a change such as a larger instance type for retraining is reviewed as a pull request instead of being clicked into the workspace UI.
Running databricks bundle init mlops-stacks and answering its prompts
The prerequisites are short: Python 3.8 or later, and Databricks CLI version 0.236.0 or later. The CLI supplies the asset bundle template machinery, so the template is not cloned directly. You create a project with one command:
databricks bundle init mlops-stacks
The command prompts for initialization parameters. The README documents three values for input_setup_cicd_and_project. CICD_and_Project sets up both halves and is the default. Project_Only generates the ML project without the pipelines, which the README frames as the easiest entry point for a data scientist working in a development capacity. CICD_Only generates only the CI/CD workflows, aimed at monorepo layouts or at adding pipelines to a project that already exists. That third option is the one that matters for incremental adoption: a team with an established repository does not have to regenerate its code to get the workflows. Beyond that first prompt, the README excerpt does not enumerate the remaining parameters, so the full prompt list has to be read from the documentation page or discovered interactively. Two status notes apply. The README marks the feature itself as public preview, and it states that Databricks asset bundles and asset bundle templates are also in public preview.
Where the template stops helping
The generated project is a starting point, and the parts that are hardest to get right are the parts a template cannot decide for you. The README describes the promotion path as cutting a new release branch as part of your regularly scheduled release process, which means the branching model, the release cadence and the approval rules are conventions your team supplies. Nothing in the repository enforces them. The CI/CD layer is also tied to two providers only: GitHub Actions or Azure DevOps. A team on GitLab CI or Jenkins gets the ML code and the bundle resource files but not the pipeline, and would have to write the equivalent workflows against the databricks CLI themselves. The environment model assumes three separate Databricks workspaces, one each for dev, staging and prod. Teams running a single workspace with isolated catalogs or schemas will find the generated configuration does not describe their setup and will need to rework the workspace references. Finally, the repository is written in Go Template, so customizing the scaffolding itself, as opposed to the projects it produces, means editing template files with the templating syntax embedded in paths and filenames. That is a real skill boundary, and it is the reason most teams should treat the template as read-only and edit the generated output instead.
Compared with a hand-rolled bundle repository
The obvious alternative is writing your own databricks.yml and job resource files, then wiring a CI pipeline around them. That approach gives you exactly the resources you need and no example code you will delete. The difference in approach is who owns the defaults. With a hand-rolled bundle, the training job definition, the test layout and the deploy steps are all decisions you make and document yourself. With MLOps Stacks, those decisions arrive pre-made, and your work becomes reviewing and adjusting them. For a team that has already built this once, the template is mostly noise. For a team starting its first Databricks ML project, the pre-made decisions are the product. The other realistic alternative is a general-purpose Python project template combined with the Databricks CLI. That gets you packaging and tests, but not the bundle resource files, so the job definitions and their deployment remain manual. The trade-off is the same in both directions: MLOps Stacks trades flexibility for a working end-to-end path on day one.
Maintenance, versions and the Apache-2.0 licence
Release cadence is uneven. The release list shows v0.3 in March 2024, v0.4 in June 2024 and v0.5 in July 2026, with the repository's last push dated September 2026. A gap of roughly two years between v0.4 and v0.5 is worth noting if you plan to track upstream: template fixes and bundle schema changes may arrive in bursts rather than continuously. The practical consequence is that an instantiated project is largely yours to maintain. Once you have generated it, upstream improvements do not flow into your repository automatically; you would have to diff the template against your generated files and port changes deliberately. The upgrade cost therefore sits mostly on your side, and it grows with how much you have customized the generated code. The licence is Apache-2.0, which permits commercial use and modification and requires that the licence and attribution notices be preserved. This is a description of the licence identifier, not legal advice; if you redistribute the template or a derivative, have your own counsel review the notice requirements.
Editorial conclusion
Adopt it if your ML work already runs on Databricks workspaces and you want the training job, the batch inference job and the pipeline that deploys them to arrive together, defined as databricks bundle resources. Do not adopt it if your training or serving stack lives outside Databricks, or if you cannot commit to running databricks bundle init and maintaining the generated repository yourself. Before you generate anything, confirm two things: that your Databricks CLI is at v0.236.0 or later, since the README states that as the minimum, and that the public preview status of asset bundles and bundle templates is acceptable for the environments you plan to touch. Then run databricks bundle init mlops-stacks and read the generated .github or .azure workflows line by line, because those files, not the template, are what will run against production.
Community notes