Databricks Apps

Databricks Apps can be deployed directly from a Git repository, and all major Git providers are supported, including GitHub, GitLab, and Bitbucket. For automatic deployments, Databricks registers a webhook on the repository and redeploys the app whenever the configured branch receives a commit; this is supported for GitHub and Azure DevOps with a private repository and a branch rather than a tag. Git-backed apps can also be deployed through the UI, CLI, API, or Declarative Automation Bundles.

Databricks Apps lets you build and host data and AI applications on Databricks, using Python frameworks such as Streamlit, Dash, and Gradio, or Node.js frameworks such as React, Angular, Svelte, and Express. Apps can be deployed from a Git repository through the UI, CLI, API, or Declarative Automation Bundles, and GitHub or Azure DevOps repositories can trigger automatic redeployment on each commit to a branch. Apps are billed per hour of compute time while running, based on provisioned capacity.

You can build Python apps with Streamlit, Dash, or Gradio, or Node.js apps with React, Angular, Svelte, or Express. Apps run on serverless compute, integrate with Unity Catalog for data governance, and use OAuth for authentication.

It depends on the authorization model: with app authorization the app runs as its own service principal, so Unity Catalog checks that service principal's grants, while with user authorization (on-behalf-of) Unity Catalog enforces the interacting user's permissions, including row-level filters and column masks. Declare only the scopes the app needs for user authorization, and configure app permissions to control which users can open the app.

Databricks Apps is a platform for building and deploying secure data and AI applications directly on Databricks, with no separate infrastructure to run. You can build Python apps with Streamlit, Dash or Gradio, or Node.js apps with React, Angular, Svelte or Express. Users sign in through your identity provider when SSO is configured. The docs do not state a general-availability date, so confirm current status with your Databricks account team.

The Databricks Apps docs do not describe App Spaces, so this answer makes no claim about them. Governance that the docs do describe: each app runs as its own service principal that needs explicit grants on each resource, and user authorization applies the user's Unity Catalog grants within approved scopes, which admins can restrict.

Keep credentials out of source code. Attach SQL warehouses, Lakebase databases and secrets to the app as app resources, then reference them in app.yaml with valueFrom. The app's service principal credentials are injected as DATABRICKS_CLIENT_ID and DATABRICKS_CLIENT_SECRET, and the docs advise against hardcoding personal access tokens.

The docs I checked have no AppKit page. For Node.js apps, the docs describe a package.json at the app root, with npm or pnpm chosen by the lock file, and an app.yaml that runs npm run start by default.

Connect the app directly to a SQL warehouse and query the lakehouse in place rather than copying data into an app-side database. Attach the warehouse as an app resource in the Apps UI or bundle config, reference its key in the env section of app.yaml with valueFrom, and let Databricks provision the app's dedicated service principal. Use On-Behalf-Of to enforce per-user Unity Catalog row-level security. Parameterize every query value, set STATEMENT_TIMEOUT at the warehouse level, and always include a LIMIT. The post gives no freshness SLA, and materialized views still need REFRESH to update.

Databricks Apps run as containerized services on the Databricks serverless platform and support UI frameworks such as Streamlit, Dash, and Gradio. Apps use OAuth 2.0 for authentication and access control. You connect an app to data and services through resources such as SQL warehouses, model serving endpoints, jobs, secrets, and volumes.

Yes. Databricks Apps can redeploy automatically on pushes to a configured branch: Databricks registers a webhook on the repository, and each push to the watched branch triggers a deployment. GitHub and Azure DevOps are supported for automatic deployments; the repository must be private, the Git reference must be a branch rather than a tag, and the app's service principal needs a Git credential with access to the repo. Repositories are limited to 20 webhooks (250 for GitHub Enterprise).

Databricks Apps runs Python web apps started by the command in app.yaml (default: python <file>). The platform substitutes DATABRICKS_APP_PORT into the command at runtime, so the server must bind to that port. Lakebase can be attached as an app resource for a Postgres database. The docs do not include a Django example, so verify your framework setup.

Databricks Apps can host a Streamlit app, a documented Python framework, and attach a SQL warehouse as an app resource so the app queries warehouse data. Access to that warehouse is set through the app's service principal, or through the user's Unity Catalog permissions for user-authorized calls.

Private Python packages can be installed by setting PIP_INDEX_URL in app.yaml with a valueFrom reference to a Databricks secret that holds the index URL with its credentials, and listing the package names in requirements.txt. The network configuration must allow access to the private repository.

Databricks Apps are hosted on serverless compute and use SSO sign-in. Access to Unity Catalog data follows the user's permissions for user-authorized calls. The Replit integration, its 15-minute setup and its plan requirements are not documented in the Apps docs and were removed.

Databricks Apps authenticate users through SSO when it is configured, and each app has its own service principal. With user authorization, the app acts with the signed-in user's identity, so the user's Unity Catalog permissions apply to those calls. Permissions are granted to users, the app service principal and approved scopes.

Lakebase is a managed Postgres (OLTP) database that can be attached to a Databricks app as an app resource, with the default key postgres for Lakebase Autoscaling. Document processing through the Replit integration and AI functions is not documented in the Apps docs.

No. Databricks Apps support both Python and Node.js. You can build with Python frameworks such as Streamlit, Dash, and Gradio, or JavaScript frameworks such as React, Angular, Svelte, and Express, then deploy to a workspace. Apps run on serverless compute and integrate with Unity Catalog, Databricks SQL, and OAuth, so the framework choice is broad rather than Python-only.

Databricks Apps are billed per hour of compute time while the app runs, based on provisioned capacity (docs). The docs I checked do not publish per-size rates, app limits or trial length, so take current figures from the pricing page and your account team.

The cited docs do not name data entry forms as a use case. Databricks Apps are general web applications built with Streamlit, Dash, Gradio, React, Angular, Svelte, or Express, running on serverless compute, and an app can be embedded in an external web page with an HTML iframe whose src is the app URL. Viewers must be authenticated Databricks users with app permissions, and the app must be running.

Apps run Python 3.11 in a dedicated, isolated virtual environment, and Databricks installs the app's dependencies into it during deployment. Declare every package the app imports, including pyspark if your app uses it, because the docs do not list pre-installed Python packages. You can confirm what is installed on the Environment tab of the app's details page.

Add a SQL warehouse as an app resource with CAN USE for query access, then grant the app's service principal SELECT on the tables it reads, or MODIFY on tables it writes. Databricks manages resource credentials automatically, so the app does not handle tokens in its code. Because these grants apply to the app's service principal, access works the same way once the app is deployed.

Databricks Apps offers two authorization models. App authorization runs the app as its own service principal, which suits shared data, while user authorization (on-behalf-of) applies the interacting user's identity and Unity Catalog permissions, including row-level filters and column masks. For user authorization, the app declares the specific scopes it needs, so per-user data access is enforced by Unity Catalog.

Databricks Apps let you build and deploy data and AI applications directly on the Databricks platform, with no separate infrastructure to manage. Apps run on serverless compute and integrate with Unity Catalog for governance, Databricks SQL for querying, and OAuth for authentication. You can develop locally and deploy to a workspace or move apps between workspaces.

Databricks Apps supports React, Angular, Svelte, and Express for Node.js apps. For Python, popular frameworks include Streamlit, Dash, and Gradio. Choose the framework your team already uses from that list.

Databricks Apps are billed per hour of compute time while the app is running, based on provisioned capacity. The docs I checked do not publish per-size rates, so check the pricing page for current figures.

The Databricks Apps docs do not mention a free trial. Free Edition is a no-cost, serverless-only, quota-limited environment for personal learning and prototyping, and it is documented separately.

By default Databricks runs Python apps with the python command on the first .py file in the app's structure. If the app includes Node.js, the default command is npm run start. You can override either default by setting the command field in app.yaml.

Set the command field in app.yaml to define a custom startup command. Databricks does not run the command in a shell, so put any values the command needs in the app configuration. The platform substitutes DATABRICKS_APP_PORT with the actual port number in the command at runtime.

Reference the DATABRICKS_APP_PORT variable in your startup command, and the platform substitutes the actual port number at runtime, so your app listens on the port Databricks assigns. Use the app's configured startup command in app.yaml to wire it in. Reference DATABRICKS_APP_PORT in your startup command so the port is set correctly at runtime.

Yes. When you create an app, Databricks automatically provisions a dedicated service principal for it, and the app uses that identity for work that does not depend on a user, such as background tasks or shared configuration. The service principal's OAuth client values are exposed to the app as DATABRICKS_CLIENT_ID and DATABRICKS_CLIENT_SECRET.

App authorization runs the app as its service principal, so all users share that identity's permissions, which suits shared data. User authorization, also called on-behalf-of, makes the app act with the identity of the user interacting with it, and Databricks enforces that user's Unity Catalog permissions, including row-level filters and column masks. Choose app authorization for shared data and user authorization when per-user access must be enforced.

For on-behalf-of user authorization, Databricks forwards the user's identity and access token in HTTP headers such as x-forwarded-access-token. The app declares the authorization scopes it needs, and those scopes define what it can do on the user's behalf. This forwarding applies to on-behalf-of user authorization.

If you do not select any scopes, Databricks assigns a default set of iam.access-control:read and iam.current-user:read, which lets the app retrieve basic user identity information. An app that needs data or compute access declares the specific scopes it requires. Declare only the scopes your app needs so its access stays limited to them.

Apps can attach a wide range of resources, including other Databricks apps, Genie Agents, Lakebase databases, Lakeflow jobs, MLflow experiments, model serving endpoints, secrets, SQL warehouses, Unity Catalog connections, tables, user-defined functions, volumes, and AI Search indexes. Each resource type has its own permission levels, and the resources page is the reference for choosing the right one. Attach each resource with the least privileges the app needs.

The user adding the resource needs Can manage on both the resource and the app. Once that is in place, grant the app's service principal only the minimum permissions it needs, as the resources page recommends. Confirm the person adding the resource holds both permissions before deploying.

A SQL warehouse resource supports Can use and Can manage. Grant Can use for apps that only run queries, and reserve Can manage for apps that need full control of the warehouse. Pair this grant with SELECT or MODIFY on the Unity Catalog tables the app uses.

A Lakebase database resource supports the Can connect and create permission, which lets the app connect to the database. The user adding the resource needs Can manage on both the resource and the app. Grant it so the app can connect to its Lakebase database.

A secret resource supports Can read, Can write, and Can manage. Grant the level the app needs, following the minimum-permissions guidance. Use Can read when the app only needs to read secret values.

A Unity Catalog volume resource supports Can read and Can read and write. Choose the level that matches whether the app only reads files from the volume or also writes to it. Pick Can read when the app never writes files back to the volume.

A model serving endpoint resource supports Can view, Can query, and Can manage. Choose the lowest level that covers what the app needs, such as Can query for inference. Grant Can query to apps that only need inference.

A Lakeflow job resource supports Can view, Can manage run, and Can manage. Choose the lowest level that matches what the app needs, following the minimum-permissions guidance. Grant Can manage run when the app only needs to trigger runs.

Reference secrets through the valueFrom setting in the app configuration, so raw secret values never appear in environment variables. Rotate secrets on a recurring basis, and sooner after team changes. Give each app access to only the secrets it needs.

Give each app its own service principal, and do not share service principal credentials across apps or users. A service principal fits when access to resources and data is the same for all users of the app, and you should rotate its credentials when the app's creators leave your organization. Keep credentials scoped to one app so rotation affects only that app.

Build a graceful shutdown so your app exits within 15 seconds of receiving SIGTERM. Apps that do not exit within that window are forcibly terminated with SIGKILL. Test your shutdown path so it completes within that 15-second window.

Open the Logs tab for the app to view standard output and error, or append /logz to the app URL to go straight to the logs. Entries are grouped by source (App, System, Build, and HTTP) so you can filter what you need. Make sure your app writes to stdout and stderr, since those streams are what appear in the logs.

Databricks does not persist app logs once app compute shuts down. To keep logs long term, export them to an external logging service, a Unity Catalog volume, or a table, which the monitoring docs recommend. Export logs to a destination you control if you need them beyond the app's lifecycle.

Databricks captures audit logs for app-related activities in the system.access.audit table. You can query that table to review app activity alongside your other audit events. Query system.access.audit alongside other audit events to correlate app activity.

The Insights tab (Beta) shows user engagement and app availability. The Viewers table keeps one record per user per app, which later visits overwrite, with a last-viewed timestamp (UTC only in Beta). The tab separates app service health, which covers the supporting infrastructure, from app availability, which covers whether the app serves requests.

Yes. Databricks Apps records an HTTP access log entry for each request your app serves, and you can filter the Logs tab by the HTTP source to review them. Platform-internal requests such as authentication callbacks and health checks are excluded, and under heavy load Databricks may drop some entries.

Run databricks sync --watch . against a workspace folder such as /Workspace/Users/<you>/my-app, and your local changes sync automatically. Then run databricks apps deploy my-app-name --source-code-path against that same folder. Redeploying applies your latest updates without recreating the app.

Use databricks apps deploy my-app --git-branch main, or the --git-tag or --git-commit flag instead. A branch or tag deploys the most recent commit on that reference, while a commit SHA deploys that exact commit. To create a Git-backed app, use databricks apps create my-app --git-url with the repository URL and --git-provider.

Add --git-source-code-path to the deploy command, for example apps/my-app, to deploy from a subdirectory of the repository. Use this flag when your app lives in a subfolder of a larger repository.

Run databricks apps list-deployments my-app to list every deployment made for that app, showing the full deployment history. Use it to audit what has been deployed. The history makes it easy to review changes over time.

Apps run the default command unless app.yaml sets one: python on the first .py file for Python apps, or npm run start when the app includes Node.js. Because that default is npm run start, a pnpm-based app should set the command field in app.yaml explicitly so the start path is unambiguous.

No. Redeploying applies your latest updates in place without recreating the app. Changing only the Git reference keeps the app's Git credentials, while changing the Git repository or switching between Git and workspace deployment sources removes the service principal's Git credentials, so plan that change deliberately.

Run databricks apps run-local --prepare-environment --debug to install the app's dependencies and prepare its virtual environment. Then open the local URL the command reports (http://localhost:8001 in the docs), and a sync process watches your local files and uploads changes to the workspace automatically. Use it to test changes before redeploying to the workspace.

The get-started flow uses the Gradio Hello world template, which follows Databricks best practices. In the Apps UI, click + Create app, choose the template, and name your app; the template creates the app and deploys it to your workspace. Use the run-local flow to iterate quickly before deploying.

Embed a Databricks app in another web application with an HTML iframe whose src attribute is the app URL. Viewers must be authenticated Databricks users with the appropriate permissions, and the app must be running and accessible in the workspace. Start from the template to get a working app with Databricks best practices built in.

Create a network connectivity configuration (NCC) to control outbound traffic from the app. NCCs provide fixed public IP addresses you can add to external system allowlists, and you can route egress to private destinations such as an S3 bucket or a network load balancer through PrivateLink.

In Private Link environments with restricted egress, apps reach specific domains during both build time and runtime, so you allowlist those domains for outbound access. Use the NCC approach to keep outbound traffic predictable. Apply the allowlisted domains for both build and runtime.

Configure front-end private connectivity to route ingress traffic through your own VPC interface endpoint, which keeps app access off the public internet. Without it, traffic to databricksapps.com can traverse the public internet depending on the user's network location. Front-end private connectivity is configured through your own VPC interface endpoint.

Enable IP access lists at the workspace level to restrict workspace and app access to your known, trusted IP ranges. Only traffic from the configured ranges is allowed. IP access lists enforce the boundary across both the workspace and its apps.

Workspace admins review and approve the app's requested access to resources during deployment. The best-practices guidance is to grant only the minimum permissions the app's service principal needs. Review each requested resource in the deployment flow before approving it.

The app.yaml file defines the command that runs your app and sets its local environment variables. It is the configuration file that tells Databricks how to start the app. Define the command there whenever the default start behavior is not what you need.

During deployment, Databricks installs the app's dependencies into the app's isolated runtime environment, so the app runs with the packages it declares. Declare dependencies so the deployment installs them. Check the Environment tab to see the installed packages.

Yes. Apps are on by default for workspaces with the compliance security profile, in regions where the selected compliance standard is available. Workspaces on a compliance profile should confirm regional availability for their chosen standard.

Add the resource in the Databricks Apps UI when you create or edit the app and assign it a resource key. Reference that key in the env section of app.yaml with valueFrom. Attaching a resource does not replace data permissions, so the app's service principal may still need table-level access such as SELECT on Unity Catalog tables.

The Can run permission on the Genie space. Databricks documents Can run as granting the app permission to submit queries to the Genie Agent and receive responses. Add the Genie space as an app resource, keep the default key genie-space or set a custom key, and map its value to an environment variable such as GENIE_SPACE_ID with valueFrom in app.yaml.

The only currently available permission is Can connect and create. The default resource key is postgres for Lakebase Autoscaling and database for Lakebase Provisioned. Databricks sets the PG* variables, such as PGHOST and PGDATABASE, only for the first database resource, so an app using several PostgreSQL databases should use valueFrom with each resource key.

Use the --compute-size flag on databricks apps create or databricks apps update. The CLI reference lists LARGE and MEDIUM as the supported values for both commands.

Place an app.yaml file in the root of your project directory and set the command field, for example command: ['streamlit', 'run', 'app.py'] for a Streamlit app. Without app.yaml, Python apps run a default command and Node.js apps default to npm run start. The DATABRICKS_APP_PORT placeholder in the command is replaced with the actual port at runtime.

Open the app's Logs tab and use the Source filter to view Build, System, and App output. Your app must write to stdout and stderr for its output to appear there. Databricks does not persist logs when app compute shuts down, so send them to an external logging service or write them to a Unity Catalog volume or table.

Sync the local project folder to a workspace path with databricks sync, and add --watch to keep uploading changes as you edit. Then run databricks apps deploy with --source-code-path pointing at that workspace folder. app.yaml is optional, but include one to set a custom command or environment variables. If a deployment fails, validate app.yaml syntax, confirm that env and secrets resolve, and check that dependencies are installed.

For Python, Databricks lists Streamlit, Dash, and Gradio as popular frameworks. For Node.js, React, Angular, Svelte, and Express are listed as supported. Apps can be developed locally and moved between workspaces, and once deployed, app settings, permissions, networking, and authorization are configured for the app.

Yes. The Databricks tutorial builds a Streamlit app with the Databricks SQL Connector for Python, reads a Unity Catalog table, and displays it in a Streamlit interface. You define how the app starts in an app.yaml file and list dependencies in requirements.txt, then deploy the app to Databricks Apps.

Databricks Apps uses pip or uv for Python dependencies and npm for Node.js dependencies, so each app declares its requirements the way its runtime expects. Databricks AppKit is a Node.js and React SDK that accelerates app development, with type-safe database queries, pre-built UI components, and a plugin system.

Yes, if you configure it: horizontal scaling runs one Databricks App across 1 to 5 instances behind a single app URL, with at most 5 instances per app and 20 horizontally scaled apps per workspace. Databricks recommends at least 2 instances for availability. Deployments are zero-downtime: Databricks deploys to one build instance first and updates the remaining instances only after that build succeeds, while existing instances keep serving traffic.