Databricks Apps

What it is

A Databricks App is a web application that runs inside your workspace instead of on infrastructure you keep somewhere else. You write it in Python — Streamlit, Dash and Gradio are the frameworks the documentation names — or in Node.js, with React, Angular, Svelte or Express. Databricks runs it on serverless compute, puts it behind the workspace’s sign-in, and gives it a URL.

The point is not hosting as such. It is that the app sits next to the data and inside the same governance: it reaches a SQL warehouse, a Unity Catalog table, a serving endpoint or a Genie agent as a declared resource, with an identity Unity Catalog already understands.

Why it exists

The usual way to put an interface in front of lakehouse data was a separate service: a container somewhere, a service account with a long-lived token, a network path back into the workspace, and a second place to audit. Every one of those is a thing to secure and a thing to forget. Apps removes the separate place. The identity, the network and the audit trail are the workspace’s own.

It is also where the platform itself is heading. The documented way to ship a custom agent is to run it as an app (Deploy an agent on Databricks Apps), a Lakebase database is attached to an app as a resource (Lakebase behind an app, an agent or a feature store), and the newest products on the radar arrive as applications on a workspace.

How it works

Two identities, chosen per request

An app always has its own service principal, created with it and unique to it. Anything the app does as itself — reading a reference table, writing a log — runs with that principal’s grants, the same for every user.

User authorization (on-behalf-of-user) is the other model. Databricks forwards the signed-in user’s access token to the app in the x-forwarded-access-token header, and the app uses it to call Databricks, so Unity Catalog applies that user’s own permissions, row filters and column masks. Scopes limit what the app may do with that token: without any, it can only read who the user is. A user is asked to consent to the scopes the first time they open the app, and an admin can consent for everyone.

The two are not exclusive. A common app reads shared configuration as itself and the user’s data as the user.

Compute, and what it costs

An app runs on one of three sizes: Medium (up to 2 vCPU, 6 GB, 0.5 DBU an hour) is the default, Large doubles it at 1 DBU, XLarge reaches 12 vCPU and 48 GB at 3 DBU. Billing is by the hour for the size you chose, while the app is running. An app does not scale up by itself; running it across several instances for availability and concurrency is configured separately.

From a folder to a URL

An app is a folder of code with its configuration. You develop it locally, deploy it to a workspace from the UI or the CLI, and promote it across environments like any other asset with Declarative Automation Bundles and the Databricks CLI and a CI/CD pipeline.

Example: the same page, two identities

A dashboard-style app shows sales by region. Read as the app’s service principal, every user sees every region, because the principal was granted the table. Switch the query to the forwarded user token and the same page shows each person only the regions their row filter allows — no change to the app’s logic, because the filter lives in Unity Catalog.

Common mistakes

• Granting the service principal everything to make a demo work. Then every user sees what the principal sees. Decide per query which identity it runs as.
• Leaving an app running that nobody uses. It is billed by the hour while it runs.
• Choosing XLarge first. Medium is the default for a reason; move up when a real app is measurably short of memory or CPU.
• Keeping a token in the code. Declare the resource and let the platform inject the credentials, or use Secrets and credentials.