Provisioning for the Agentic Era: How Databricks Built a Self-Serve Infrastructure Vending Machine

Provisioning for the Agentic Era: How Databricks Built a Self-Serve Infrastructure Vending Machine | Databricks Blog Skip to main content

Summary

Why scaling GTM to 7,000+ people created new infrastructure challenges around workspace isolation, governance and cost visibility.

How we built the FE Vending Machine — a Databricks App that provisions isolated, governed, use-case-specific cloud resources on demand

FE Vending Machine allows our GTM organization to build with velocity, leverage an agent-first framework at scale, and move as fast as technology changes

At Databricks, our field engineering organization exists to help customers succeed. That means building demos, reproducing issues, testing features against real workloads, and being ready (on short notice) to show a prospect exactly what's possible on the platform. Never has this been more imporant than in the age of AI, where a single week can mean a fundamental shift in what is possible. As Databricks has grown, it has become more important- and more challenging- to enable our field organization in a way that's fast, governed and cost-aware. To solve that problem, we set out to build the Field Engineering Vending Machine, or FEVM for short. Like any good vending machine, the idea is simple: you say what you need, you get it, and when you're done, it goes away. Perhaps most importantly, FEVM is built with Databricks-native components at its core, and agents as first-class citizens. Growing pains at scale Just over three years ago, field engineering was under 1,500 people. A small number of shared workspaces covered most use cases, and manual maintenance kept things running reasonably well. But Databricks grew fast. GTM is now over 7,000 people, with field engineering making up a significant portion of that. Infrastructure that worked at one size needs a different design at another. Databricks workspaces are optimized for a small number of administrators managing many users, which makes sense for most enterprise deployments. Field engineering has different requirements, however: nearly everyone needs admin-level access to actually do their jobs. Configuring demo environments, testing preview features, running customer-specific scenarios — all of it requires the kind of control that admin access provides. At scale, coordinating work across shared workspaces creates real operational complexity. Multiple engineers working in the same environment during a critical demo moment can interfere with each other's work, and platform limits — on catalogs, Lakebase instances and concurrent workloads, for example — become an active concern rather than a background one. Cost attribution grows harder to track as usage increases and ownership becomes less clear. The observability problem also compounded these challenges. When something unexpected happened in a shared workspace, tracing what occurred, when and why required manual investigation. We needed a model that made every provisioning action transparent, auditable and attributable from the start. The insight that shaped FEVM was straightforward: what if every engineer could have their own isolated environment, provisioned in minutes, governed centrally and cleaned up automatically? Building on Databricks, for Databricks When Databricks Apps became available, the opportunity was clear. We had been maintaining environments through a collection of individual jobs — one job per task, running separately and always slightly behind reality. Apps gave us a way to abstract all of that behind a single interface: tell us what you're trying to accomplish in plain english, and we'll figure out what infrastructure to provision. That became the core design principle for FEVM: use-case-based provisioning. You don't request "a workspace." You describe what you're trying to do, whether it’s building a demo for a financial services customer, reproducing a support issue, running a hackathon session, and you get an environment configured for that purpose. This is all abstracted with an MCP at its core, meaning that chat, external services, and agents are all served from a single point of control; with the rise of tools like Claude, this means that adding a simple .md skill file allows you to ask for a new environment on the command line in plain english and log in minutes later. More complex workflows become similarly trivial from a user perspective. The app is built on a React frontend with a Python backend, deployed via Databricks Apps. Terraform runs in the background to handle actual cloud resource provisioning across AWS, Azure and GCP. A state and configuration database - run on Lakebase - tracks every resource: what it is, who owns it, what it's for, when it expires. The Databricks Apps development experience itself was straightforward. The more complex work was integrating into the broader ecosystem: wiring up Git-based workflow launches, handling identity across corporate systems, and ensuring that automating administrative actions against real backend infrastructure stayed within our security boundaries. We operate under a number of security exceptions for exactly this reason and have been deliberate about designing for good stewardship at every step; new templates are vetted, hardened, and tested repeatedly to make sure they do not expose new threat vectors.

Figure 1: High level architecture diagram of FEVM

What the app does When a field engineer opens FEVM, they're greeted with a search interface. They can browse a template catalog to find the right environment type — stable serverless on AWS, a multi-cloud setup, an environment with Lakebase autoscaling pre-configured, for example — and configure from there. They choose a cloud provider and region, describe what they're building, give it a name (or accept a random one), and deploy. More recently, we’ve enabled agent-first workflows that allow users to leverage centrally published claude skills; this is an increasingly popular option that allows agents to automate away the UI and go directly to underlying FEVM APIs. This becomes especially powerful in multi-step and multi-tool workflows; for example, a user might tell their agent to spin up a new workspace, deploy several DABs that they’ve developed locally, and upload some data they have in S3, and then run a hydration script to populate a dashboard. This type of hyper-personalized setup would not be possible without a strong...