Does Databricks Apps support customer-facing apps?

Summary

• It depends on what customer-facing means. Databricks Apps require every user to sign in, so they aren't public, anonymous consumer websites, but they can serve external customers and partners who authenticate.
• Apps can't be made public. Anonymous access and bypassing single sign-on aren't supported; every user is authenticated through your identity provider.
• External users are supported once provisioned. Sync external customers, partners, or vendors into your Databricks account through your identity provider with SCIM and just-in-time provisioning, then grant them app permissions.
• For an anonymous, consumer-scale audience, build a separate front end and use Databricks as the governed backend for data and model serving.
• Access stays governed. Apps run under CAN_USE and CAN_MANAGE permissions and reach data through Unity Catalog, using either the app's service principal or the signed-in user's identity.

Does Databricks Apps support customer-facing apps?

It depends on what you mean by customer-facing. Databricks Apps are built for authenticated users, not anonymous visitors, so you can't turn one into a public website that anyone reaches without signing in. Databricks Apps can't be made public, and bypassing single sign-on isn't supported. But if customer-facing means giving specific external customers, partners, or vendors access to an app, that is supported: you provision those users into your Databricks account through your identity provider, and they sign in with SSO like any other user. For a truly public, anonymous audience, the pattern is to build a separate front end and use Databricks as the governed backend.

What "customer-facing" can mean here

The term covers two very different scenarios, and Databricks Apps handle them differently.

Audience	Supported by Databricks Apps?	How it works
Internal employees	Yes	Users sign in with workspace SSO; there's no separate login to build
Named external customers, partners, or vendors	Yes, once provisioned into your account	Onboard them through your identity provider with SCIM and just-in-time provisioning, then grant app permissions
Anonymous public visitors	No	Apps can't be public; build a separate front end that calls Databricks as a governed backend

The dividing line is authentication. Every Databricks App user signs in and is a member of your Databricks account. That makes Apps a strong fit for governed internal tools and for portals shared with a known set of external collaborators, and a poor fit for an open consumer website.

How Databricks Apps handle identity and access

• Authenticated by default. Users are redirected to sign in through your workspace identity provider before the app loads. Anonymous access and SSO bypass are not supported. See configure permissions for a Databricks app.
• Account membership, including external users. App users must belong to the Databricks account where the app is deployed, though not necessarily the same workspace. To include external collaborators, sync them into the account from your identity provider using SCIM and just-in-time provisioning, which grants access without full workspace access. See Databricks Apps key concepts.
• Two authorization models. With app authorization, the app acts as its own service principal for work that doesn't depend on who is signed in. With user authorization, the app acts on behalf of the signed-in user, so access to governed resources like a SQL warehouse follows that user's own permissions. See configure authorization in a Databricks app.
• Explicit permissions. You grant CAN_USE or CAN_MANAGE on each app to specific users or groups, and data access runs through Unity Catalog, so an app only reaches what its identity is entitled to.

Choosing between an app and a public front end

If your users will authenticate, whether they're employees or a defined set of external customers, a Databricks App keeps the whole thing on the platform: the interface, the governed data access, and the identity model in one place. If you need an open, anonymous, consumer-scale website, keep that front end separate and have it call Databricks for data and model serving through governed APIs. The sensitive parts stay behind authentication, while the public surface itself does not run as a Databricks App.

FAQs

Can I make a Databricks App publicly accessible to anyone?

No. Databricks Apps can't be made public. Anonymous access and bypassing single sign-on are not supported, so every user signs in first.

Can external customers or partners use a Databricks App?

Yes, if you provision them into your Databricks account through your identity provider with SCIM and just-in-time provisioning. They then sign in with SSO and use the app under the permissions you grant, without full workspace access.

How do I build a truly public, consumer-facing app with Databricks?

Build the public front end outside Databricks Apps and have it call Databricks as a governed backend for data and model serving. Reserve the Databricks App itself for authenticated employees and external collaborators.

How does a Databricks App access data securely?

Through Unity Catalog. App authorization uses the app's service principal, while user authorization acts on behalf of the signed-in user, so every request is subject to the same governance as the rest of your data.