TL;DR
Databricks Apps is a managed way to host Python or Node.js web apps on Databricks serverless compute, inside your own workspace. Each app reaches data through Unity Catalog, Databricks SQL and OAuth, so there is no separate infrastructure to run. You can start from a template, build locally with the Databricks CLI, and deploy from the workspace or a Git repository. An app runs either as its own service principal or on behalf of the signed-in user, and that choice decides who sees which rows. Billing is per hour while the app runs, at 0.5, 1 or 3 DBUs depending on the instance size. Keep state outside the container, because in-memory data and local files disappear when the app restarts.
Key Takeaways Apps host data and AI web apps built with Streamlit, Dash, Gradio, React and similar frameworks right next to the data they use. Resources such as SQL warehouses, model serving endpoints and Lakebase databases are declared in code and bound at deployment, so one codebase moves from dev to prod. App authorization runs as a shared service principal, while user authorization runs as the viewer so Unity Catalog row filters and column masks apply. You pay only while an app is running, from 0.5 DBU per hour on Medium to 3 DBU per hour on XLarge, plus the warehouses and endpoints it calls. Persist anything that matters in Databricks tables, Unity Catalog volumes or Lakebase, since container memory and local files don’t survive a restart. A workspace holds at most 100 apps, a fixed limit, and an app’s URL can’t be changed after creation. Watch on YouTube
Databricks Developer Hiring: 2026 Skills, Cost & the Spark Job Test
Kanerika walks through the skills teams look for in Databricks developers in 2026, a useful lens when you decide who should build and own your first app.
A Developer’s Day Building One Internal Data App
Say a data engineer at a hypothetical regional distributor opens a request from finance at 9 a.m. The team wants to review flagged invoice exceptions, approve or correct each one, and stop emailing spreadsheets back and forth. The data already sits in Unity Catalog tables, and a dashboard shows the exceptions, but nobody can act on them there.
By 10:30 she has a template app running in the workspace. Lunch goes to wiring it to a SQL warehouse and deciding where approvals get written, because a restart would wipe anything held in memory. Then the afternoon turns to identity. Should every analyst see every vendor, or only the vendors their own permissions allow?
At 4 p.m. the app is live at a workspace URL, behind the same single sign-on finance already uses. She set up no new server and no separate login system. That compressed day is the promise of Databricks Apps, and whether it holds depends on four decisions about resources, authorization, state and cost.
What Are Databricks Apps?
Databricks Apps lets developers build and deploy data and AI applications directly on the Databricks platform, with no separate infrastructure to run. Apps run on serverless compute, the official documentation explains. They connect to Unity Catalog for governance, Databricks SQL for queries and OAuth for authentication. Databricks says on its product page that the service is built for data scientists, engineers and developers who need to turn prototypes into production applications.
The gap it closes sits between analysis and action, which is where users actually do their work. A notebook holds code and a dashboard shows numbers. Yet neither gives a business user a form to fill, a button to approve or a chat box grounded in company documents. Before Apps, that last step meant copying data to a separately hosted web app, so teams kept a second security model beside the Databricks platform .
The service entered public preview in November 2024 and became generally available on June 11, 2025. At that point Databricks reported more than 20,000 apps built and over 2,500 customers using them, according to its general availability announcement .
Where Apps Fit Beside Notebooks, Dashboards and Genie
Go back to the invoice-exception example. First, a notebook is where the engineer writes the logic that flags a bad invoice. A dashboard shows finance how many exceptions arrived this week. Then a Genie Agent (renamed from Genie space in July 2026) lets someone ask about them in plain English, as our Databricks Genie guide explains.
Finally, the app is where an analyst opens one exception, checks it, and approves or corrects it. So a short rule of thumb follows. Notebooks are for building, dashboards are for reading, Genie Agents are for asking, and apps are for acting.
When users only need to read or ask, an app is extra work. In that case the conversational and dashboard tools covered in our guide to generative BI are the shorter path.
What Teams Build With Databricks Apps
Databricks names four common patterns, and each one maps to a familiar business request.
Interactive dashboards. Views with custom logic that a standard dashboard can’t express, such as a pricing simulator with editable assumptions.RAG chat apps. A chat interface that answers from approved internal documents, built on retrieval-augmented generation .Data entry forms. Screens where people add or correct records, like the invoice-exception queue above.Custom operational interfaces. Tools for running a process, for example triggering a Lakeflow job or reviewing model outputs before release.Agent front ends are also a newer fifth pattern. Databricks published documentation for authoring and deploying AI agents on Apps in February 2026. Then in April 2026, the Agent Bricks Supervisor Agent gained support for custom agents and MCP servers hosted on Apps. Our Agent Bricks overview puts that in context.
How Databricks Apps Work
A Databricks app is a web application that runs as a containerized service on the Databricks serverless platform. The container holds your code and its dependencies. Everything heavy, such as querying data, serving a model or storing transactions, happens in other Databricks services that the app calls.
A single request moves through four steps.
A user opens the app URL in a browser and signs in with their Databricks identity. Databricks terminates TLS and forwards the request to the app container. The app code calls a declared resource, such as a SQL warehouse, a model serving endpoint or a Lakebase database. Finally, the result returns to the container, which renders the page or the API response. That split also keeps the app small. The container handles the interface and the business logic, while governed services do the data work. As a result, you size the app for its users rather than for the data volume behind it.
The Runtime: A Container on Serverless Compute
Apps also share the isolation layers of Databricks serverless compute , including dedicated compute resources, network segmentation, and encryption at rest and in transit. The container can still connect to non-serverless resources, such as a classic SQL warehouse.
The current system environment is Ubuntu 22.04 LTS with Python 3.11 and Node.js 22, and uv can pin a different Python version. By default, each app can use up to 2 vCPUs and 6 GB of memory.
Every app also receives a fixed address in the form https://<app-name>-<workspace-id>.<region>.databricksapps.com. Because the URL can’t be changed after creation, choose the app name as carefully as you would a production hostname.
Resources: Declared in Code, Bound at Deployment
Resources, in short, are how an app reaches the rest of Databricks. During development, you declare what the app needs in its configuration, such as a SQL warehouse. Then at deployment you bind that declaration to a real instance. So the same code can point at a dev warehouse first and a prod warehouse after release.
Apps can’t, however, create resources of their own. Instead, they use existing ones, and the app’s service principal receives the permissions granted on each. Supported types include SQL warehouses, model serving endpoints, Unity Gateway model services, Genie Agents and Lakebase databases. Lakeflow jobs, MLflow experiments, secrets, Unity Catalog volumes, AI Search indexes (formerly Vector Search) and other apps are supported too.
Review that list the way you would review a dependency file, because each entry is a permission the app’s identity holds. Access to the underlying tables still runs through Unity Catalog , which keeps the app inside the same governance model as every other workload.
Where App State Should Live
Apps don’t preserve in-memory state after a restart, and files written to the container’s local disk also disappear. So a prototype that keeps approvals in session state will lose them at the first redeploy.
Storage option Survives a restart? Best for In-memory state (session variables, caches) No Temporary interface state within one session Local files in the container No Scratch files during a single request Databricks tables via Databricks SQL Yes Audit records and results other teams query Workspace files Yes Small configuration and reference files Unity Catalog volumes Yes Uploaded documents, images and other files Lakebase (PostgreSQL-compatible) Yes Transactional records, sessions and row-by-row approvals
In the invoice example, approvals belong in Lakebase or a Delta table rather than a Python dictionary. Lakebase suits many small writes that the app reads straight back, while a Databricks table suits records that mainly feed reporting.
App Lifecycle and When You Pay
An app moves between four states, described in the Databricks concepts guide . Running is the only state that bills, since Databricks charges for compute while the app runs. Stopped apps are inaccessible but keep their configuration and cost nothing, and apps that are Deploying or Crashed incur no charge either.
So stop development and demo apps when they sit idle, then start them again when someone needs them.
Which Frameworks Can You Use?
Apps are written in Python or Node.js, so the choice starts with language. Databricks names Streamlit, Dash and Gradio as popular Python frameworks, and it says Node.js frameworks such as React, Angular, Svelte and Express are supported too.
Framework Language Best fit Watch out for Streamlit Python Fast internal tools, data entry forms, simple dashboards Script-style apps get harder to structure as screens multiply Dash Python Analytical views with many linked charts and callbacks More code per screen than Streamlit Gradio Python Model demos and chat interfaces Narrower fit for multi-step business workflows Python web frameworks such as Flask or FastAPI (examples) Python APIs, agent back ends, custom HTML You build the whole interface yourself React, Angular or Svelte with Express Node.js Polished front ends for wide internal audiences No Node libraries are pre-installed, so manage every package yourself
Each template ships with an app.yaml manifest that defines the command that runs the app and its environment variables. Python apps add a requirements.txt file, or a pyproject.toml for uv-based dependency management, while Node.js apps use package.json.
Pick the framework your team already maintains, because a familiar framework makes review and handoff easier once real users depend on the app.
Kanerika Service
Databricks Consulting and Implementation
Kanerika designs, builds and runs Databricks lakehouse, governance and AI workloads, from architecture through production support.
Explore Databricks Services How to Build and Deploy Your First Databricks App
The official Databricks Apps quick start takes you from a template to a running app in a handful of steps. The version below follows it, then adds the checks a production team runs before anyone else opens the link.
Check Prerequisites
You need a workspace in a region that supports serverless compute, permission to create apps, and Databricks CLI 0.229.0 or above configured on your machine. You also need access to every resource the app will call, such as a SQL warehouse.
If your workspace uses the compliance security profile, Apps is on by default in regions where the selected compliance standard is available. Either way, your own app code still needs a security review.
Create an App From a Template
First, in the workspace, click + Create app and choose a template, such as Gradio Hello world. Databricks then deploys the template automatically. When the status shows Running, open the URL on the app’s page to see it live.
Pull the Code, Run It Locally, Redeploy
The app’s page lists the exact commands for your folder, and they follow this pattern.
# 1. Copy the deployed app's files (app.py, app.yaml, requirements.txt)
databricks workspace export-dir /Workspace/Users/<you>/<app-folder> .
# 2. Watch local edits and upload them to the workspace
databricks sync --watch . /Workspace/Users/<you>/<app-folder>
# 3. Test locally, either directly or with the debugger
python app.py
databricks apps run-local --prepare-environment --debug
# 4. Redeploy with the deploy command copied from the app's pageThe export brings down app.py for the interface and logic, app.yaml for configuration such as the entry point, and requirements.txt for Python packages. If you write much of that code with an AI assistant, our guide to the Databricks Assistant covers what it handles well inside the workspace.
Deploy From Git Instead
For shared apps, deploy from a Git repository instead, as the Databricks deployment guide describes. The app reads code from a branch, tag or commit on each deploy, and GitHub, GitLab and Bitbucket are all supported.
databricks apps update gradio-hello-world \
--git-url https://github.com/org/repo --git-provider gitHub
databricks apps deploy gradio-hello-world --git-branch mainYou can also switch between workspace and Git sources at any time. In addition, for GitHub and Azure DevOps repositories, automatic Git deployments can redeploy the app on every push to a branch. For a private repository, add a Git credential for the app’s service principal, because that identity is the one that pulls the code.
Test It Before You Share It
Before sharing the URL, run these six checks against a test deployment.
Open the app as an allowed user and complete the main task end to end. Open it as a user without permission and confirm access is refused. Remove or rename a resource in a test deployment and check the error message is readable. Force a downstream failure, such as a stopped warehouse, and confirm nothing half-saves. Restart the app and confirm saved records are still there. Confirm the app shuts down within 15 seconds of a SIGTERM signal, which the platform requires. Give checks two and five the most attention, because one tests identity and the other tests where state lives.
Checklist
Data Engineering Checklist for Enterprise Teams
A practical checklist for production data work, covering testing, monitoring, ownership and the checks that keep pipelines and the apps on top of them reliable.
Get the Checklist → How App Authentication and Permissions Work
Authorization is where a quick prototype and a production app split apart. The authorization docs describe two models, and an app can use either one or both together.
Model Runs as Use it for Risk to test App authorization The app’s own service principal, shared by every user Logging, shared configuration, calls to external services Every user inherits the same data access User authorization The signed-in user, on their behalf Querying Unity Catalog data with row filters and column masks Scopes broader than the app needs Both Service principal for shared tasks, user identity for data Apps that log metrics and also query filtered data A code path that calls with the wrong identity
App Authorization vs User Authorization
With app authorization, Databricks creates a service principal for each app, and all users share its identity and permissions. Credentials arrive as the DATABRICKS_CLIENT_ID and DATABRICKS_CLIENT_SECRET environment variables, so the code never stores a password.
User authorization, however, works differently. The app acts with the signed-in user’s identity, which means Unity Catalog row-level filters and column masks apply exactly as they would in a notebook. The app also has to declare scopes such as sql, genie or files, on top of the defaults iam.access-control:read and iam.current-user:read.
Users consent once per app and set of scopes, and workspace admins can restrict which scopes developers may add. Still, one limit is easy to miss. The forwarded user token only works in the workspace where the app runs. To reach a warehouse in another workspace, deploy the app there or use machine-to-machine OAuth with a service principal.
Who Can Open the App
You share an app by granting CAN_USE or CAN_MANAGE. Users don’t need to belong to the same workspace, but they must belong to the same Databricks account. So to include external users, first sync them into the account through your identity provider.
Apps can also be embedded in another web application with an iframe. Even then, viewers must be authenticated Databricks users with permission on the app. Therefore, Apps is not a host for anonymous public sites.
Opening the app and reading its data are two separate permissions. Single sign-on gets a user through the door. After that, Unity Catalog decides what each user sees, but only when the app uses user authorization.
A Least-Privilege Checklist
Databricks publishes its own best practices for user authorization, and they translate into a short review list.
Request only the minimum scopes the app needs. Grant CAN MANAGE only to trusted senior developers. Grant CAN USE only to approved users or groups. Never print, log or write tokens to files. Require peer review before an app reaches production. Record structured audit logs of actions taken on a user’s behalf. An app that fails item one or four should not ship, however useful it looks. Also, the wider controls in our Databricks security guide still apply.
Watch on YouTube
Databricks Unity Catalog Explained!
A short Kanerika explainer on Unity Catalog, the layer that decides what each user can see once user authorization is switched on in an app.
Running Databricks Apps in Production
Moving from a deployed template to production changes three things, namely cost control, scaling and visibility.
Compute Sizes and What Drives Cost
Databricks bills apps per hour of compute while they run, based on provisioned capacity. The compute size documentation lists three instance sizes.
Size vCPUs Memory DBU per hour Notes Medium Up to 2 6 GB 0.5 Default when no size is set Large Up to 4 12 GB 1 Heavier in-app processing or more concurrent users XLarge Up to 12 48 GB 3 Available only in some regions
So total cost is the DBU rate times the hours running times the number of instances. On top of that come the resources the app calls, such as SQL warehouse time, model serving and Lakebase. The dollar price per DBU depends on your cloud, region and contract, so check the official Apps pricing page for your own rate.
To track spend per app, query the system.billing.usage table, and use usage policies to attribute cost to a team. Our guide to Databricks cost optimization covers the warehouse side of an app’s bill.
Datasheet
Build a Modern Data and AI Foundation with Databricks
Kanerika’s datasheet on building a governed Databricks foundation for analytics and AI, the base every production app depends on.
Download the Datasheet → Scaling, Networking and Release Automation
Horizontal scaling runs one app on 1 to 5 instances behind the same URL, and Databricks recommends at least 2 for availability. It reached general availability in the September 2026 release notes. Cost scales linearly with instances, while session affinity is best-effort and rolling deployments avoid downtime.
Network controls, meanwhile, follow the serverless compute plane. Ingress is managed with IP access lists and front-end private connectivity, and egress runs through network policies. The networking guide warns that in Private Link setups with restricted egress, missing allowlist domains commonly cause deployment failures.
For releases, Databricks documents automated app deployments from GitHub using GitHub Actions and Declarative Automation Bundles (formerly Asset Bundles) . Bundles keep the app, its resources and its permissions in version control. For the wider release discipline, see our list of Databricks best practices .
Monitoring, Telemetry and Code Scanning
Anything an app writes to stdout or stderr shows up in its logs in the UI, while audit events land in system tables. App telemetry can also write traces, logs and metrics to Unity Catalog tables, and the Insights tab, in Beta as of November 2026, shows viewers and availability.
Code security scanning, also in Beta, runs static analysis on each deployment that changes source code. It never blocks a deployment, and findings appear on the app’s Security page, sometimes with false positives.
The platform also sets runtime rules worth checking in review. The app must listen on 0.0.0.0 at the port in DATABRICKS_APP_PORT, support HTTP/2 cleartext and run as a non-privileged user. Heavy processing belongs in SQL warehouses, jobs or model serving rather than inside the container, a principle that also drives well-built Databricks workflows .
When Your App Needs Lakebase, Genie or an AI Agent
A read-only app needs none of these. Once users start writing data, holding sessions or asking questions, though, three Databricks services come into play as declared resources.
Lakebase is the choice for transactional writes such as approvals, comments or session data. New Provisioned databases can’t be created after March 12, 2026, so new apps should use Lakebase Autoscaling. Adding the resource creates a Postgres role for the app’s service principal with CONNECT and CREATE privileges. Our Databricks Lakebase guide explains in more depth.
Watch on YouTube
Databricks Lakebase: Architecture, Pricing & Zero-Downtime Migration
Kanerika explains how Lakebase works and what it costs, useful context before you give an app a transactional store for approvals or sessions.
A Genie Agent added as a resource gives the app natural-language questions over governed data. Similarly, a model serving endpoint or an AI Search index supplies generation and retrieval for a chat app. For the model side, see our Mosaic AI overview .
When Should You Choose Databricks Apps?
Choose it when your data, models and governance already live in Databricks and your users need to act, not only read. In that situation the app inherits Unity Catalog permissions and runs next to the data. The other options below are continuations for jobs Apps doesn’t target.
How Apps Compare With the Usual Alternatives
Option Primary job Best fit Who owns security Who owns operations Databricks Apps Interactive data and AI apps inside the workspace Users act on governed Databricks data Unity Catalog plus app or user authorization Databricks runs the compute, you own the code Power BI Reports and dashboards Read-mostly analytics for business users Power BI and Microsoft Fabric permissions Microsoft runs the service, you own the reports Streamlit in Snowflake Streamlit apps inside Snowflake Teams whose data lives in Snowflake Snowflake role-based access control Snowflake runs the runtime, you own the code Custom hosting Any web app Public sites or very specific needs Your team, end to end Your team, end to end
Power BI stays the stronger fit for read-mostly reporting, and Streamlit in Snowflake plays the same role for Snowflake estates. Our comparison of Databricks vs Snowflake and the Streamlit in Snowflake guide go further if your data spans both.
Five Questions Before You Commit
Fit. Is the data already on Databricks and governed in Unity Catalog?Interaction. Do users need to act, such as approve, edit or ask, rather than just read?Trust boundary. Should every user see the same data, or does each user see different rows?State. Where will written data persist, and does that store survive a restart?Ownership and cost. Who owns the app after launch, and is its spend tracked per app?Five clear answers mean proceed. If one or two answers are unclear, prototype first on a template and settle them before launch. If the answer to question two is no, pick something simpler, such as a dashboard or a Genie Agent.
Three hard limits belong in the same review. First, a workspace holds at most 100 apps, and that limit can’t be raised. Second, the app URL never changes. Finally, every user must belong to the same Databricks account.
How Kanerika Helps Teams Build on Databricks
Kanerika is a certified Databricks partner, and its teams hold 250+ technology certifications across Microsoft, Databricks and Snowflake. For a team planning its first app, a sensible sequence runs in five stages.
Use-case triage. Run the five questions above to confirm an app is the right tool.Architecture and identity design. Choose app, user or combined authorization and map resources per environment.Prototype on a template. Build the main workflow against real, governed data.Production hardening. Add Declarative Automation Bundles, scaling, monitoring and per-app cost tracking.Handoff. Name an owner and document the runbook.The proof below comes from Kanerika’s wider Databricks delivery rather than from an Apps project. For one of the largest US retail corporations, Kanerika migrated business-critical applications from on-premise PostgreSQL and Cassandra to Databricks with zero downtime. It redirected each application to Databricks workspaces after validation, decommissioned 100% of the legacy infrastructure and centralized governance, lineage and data access.
For a sales-intelligence platform, Kanerika refactored document workflows from JavaScript to Python in Databricks. The result was 80% faster document processing, 95% improved metadata accuracy and 45% accelerated time-to-insight. You can see the full scope on Kanerika’s Databricks services page and its Databricks partnership page .
Four pitfalls deserve a plan from day one: over-privileged service principals, state kept in memory, untracked warehouse costs and apps with no named owner. Teams that need extra hands for the build can also hire Databricks developers through Kanerika, while broader programs run through its data engineering services .
Case Study
Zero-Downtime Databricks Migration for Retail Analytics
Kanerika moved a large US retailer’s business-critical applications from PostgreSQL and Cassandra to Databricks with zero downtime and 100% of legacy infrastructure decommissioned.
Read the Case Study → Building Apps That Last Past the Demo
Databricks Apps hosts Python and Node.js web apps on serverless compute inside your workspace, governed by Unity Catalog and OAuth. You build one from a template, develop locally with the CLI, and deploy from the workspace or Git. Then the real work starts. Choose app or user authorization on purpose, keep state in tables, volumes or Lakebase, size compute in DBUs and stop idle apps. Get those four decisions right, and the developer’s one-day app becomes a tool the business can trust.
Frequently Asked Questions
What are Databricks Apps?
Databricks Apps is a managed service for building and hosting data and AI web applications directly on the Databricks platform. Apps run as containers on serverless compute and connect to Unity Catalog, Databricks SQL and OAuth. Teams use them for interactive dashboards, RAG chat apps, data entry forms and operational tools, without running separate infrastructure.
How do I deploy a Databricks app?
Click Create app in the workspace and pick a template, which deploys automatically. Then export the code with the Databricks CLI, develop locally, sync changes back and redeploy with the deploy command from the app’s page. For shared apps, deploy from a Git branch, tag or commit instead, and, for GitHub or Azure DevOps, consider automatic deployment on every push.
Which frameworks does Databricks Apps support?
Apps are written in Python or Node.js. Databricks names Streamlit, Dash and Gradio as popular Python frameworks, and it supports Node.js frameworks such as React, Angular, Svelte and Express. Other Python web frameworks, such as Flask or FastAPI, can run too, since the platform hosts a containerized web app listening on its assigned port.
How much does Databricks Apps cost?
Apps are billed per hour while running, based on instance size. Medium uses 0.5 DBU per hour, Large uses 1 DBU and XLarge uses 3 DBU. Multiply by hours running and the number of instances, then add the SQL warehouses, model serving and Lakebase the app calls. Stopped apps cost nothing, so stop idle ones.
Does a Databricks app use my permissions or a service principal?
It can use either, or both. App authorization runs every request as the app’s own service principal, shared by all users. User authorization runs queries as the signed-in user, so Unity Catalog row filters and column masks apply. Apps that do both shared and user-specific work can combine them, logging with the app identity and reading data with the user’s.
Do I need Lakebase to use Databricks Apps?
No. A read-only app can query Databricks tables through a SQL warehouse and needs nothing else. Lakebase becomes useful when the app writes many small transactional records, such as approvals, comments or sessions. New apps should use Lakebase Autoscaling, because new Provisioned databases can no longer be created after March 12, 2026.
Can users outside my workspace use a Databricks app?
Yes, as long as they belong to the same Databricks account and have CAN_USE permission on the app. External users must first be synced into the account through your identity provider. Embedding the app in another site with an iframe still requires viewers to be authenticated Databricks users, so anonymous public access is not supported.
How many apps can I create in a workspace?
Each workspace can hold up to 100 Databricks apps. Databricks lists this as a fixed limit, which means the account team cannot raise it on request. Teams with many small tools should group related screens into fewer apps, retire unused ones, and spread separate business units across workspaces where that matches their governance model.
Can Databricks Apps replace Power BI?
Not for reporting, because they solve different jobs. Power BI is built for reports and dashboards that business users read and share. Databricks Apps suits interactive tools where users act on governed data, such as approving records or chatting with documents. An organization can run both, with Power BI for reporting and Apps for workflows.
Can I change a Databricks app's URL after creating it?
No. Each app gets a fixed address that combines the app name, the workspace ID and the region under the databricksapps.com domain, and it cannot be changed after creation. Choose the app name carefully before the first deploy, and use a short, stable name that will still make sense once the app reaches production users.
