Databricks APPS

[smithsonian]

Hi All

We have a Databricks App built.  What is the best way for customers to access this Databricks App?

I was hoping for a central market place where the App would be published and any Databricks customer can access it with their subscription. But there not seem one. The marketplace I saw was for data providers.

Is the Databricks App a local construct?  That is, each Enterprise customer has to deploy the app locally into their environment?

Any info / best practices would be appreciated.

[edonaire]

Yes, that’s essentially correct.

Databricks Apps are currently scoped to a single workspace, so there isn’t a centralized marketplace where you can publish an app once and have multiple customers consume it directly.

The Databricks Marketplace is focused on sharing data assets, such as datasets, notebooks, and ML models, rather than full application distribution.

In practice, most teams package their app (typically via a Git repository) and have each customer deploy it within their own workspace. When scaling this across multiple clients, it’s common to automate the deployment using Terraform or the Databricks CLI as part of a standardized onboarding process.

It’s not yet a fully mature distribution model, but given that Databricks Apps is still relatively new, this is the current best practice.

[smithsonian]

Thanks. This is very helpful. 

[Lu_Wang_ENB_DBX · Accepted solution]

As of today, there is no cross-account “App Store” / marketplace for Databricks Apps themselves. Databricks Marketplace is for data products and (recently) MCP servers, not Databricks Apps UIs

---

1. Databricks App is “local”

Databricks Apps are workspace-scoped objects, tied to a single Databricks account.

Key points:

• An app belongs to one workspace, with its own identity, config, and runtime.
• You can share it with users and groups in that Databricks account, and even choose “Anyone in my organization can use” so all account users get CAN_USE on it.
• You can’t make Databricks Apps public or anonymous; access always requires SSO to the account, and anonymous/public internet users are not supported.

So for each customer (separate Databricks account) you want to serve, they need their own app instance deployed into their workspace.

---

2. How to distribute your app to many customers

The current best practice is to treat your app like a productized codebase and provide a deployment story per customer:

a) Git + Databricks Apps + CLI / UI (recommended)

• Put your app code in a Git repo.
• For each customer:
  • They pull or fork your repo into their own Git system.
  • They create an app and deploy from workspace files or from Git using the Apps UI or CLI.
• This gives you:
  • Clear versioning (tags/branches per release).
  • The ability to give them upgrade instructions (pull new tag, run databricks apps deploy).

b) CI/CD + Declarative Automation Bundles (for more mature customers)

• Package the app as an app resource in a Declarative Automation Bundle so deployment is one command (databricks bundle deploy).
• Customers wire that into their own CI/CD tooling (GitHub Actions, Azure DevOps, etc.) for dev/stage/prod workspaces.

---

3. When to use Databricks Marketplace

Marketplace is currently for:

• Data products (tables, volumes, models, notebooks) shared via Delta Sharing.
• MCP servers: you can list Model Context Protocol servers (which may be powered by a Databricks App under the hood) so other Databricks users can install them and use them as tools from their agents.

If your “app” is really a tool for agents (e.g., an MCP server backed by your app) this can be a distribution channel. But it doesn’t yet give you a GUI app marketplace like “App Store for Databricks Apps.”

---

To summarize:

1. Assume each customer deploys the app into their own workspace/account.
2. Ship:
   • A public Git repo (or partner repo) for the app.
   • A Deploy Guide with:
     • Required entitlements (Premium tier, Apps enabled).
     • databricks apps create / apps deploy commands or UI clicks.
     • Any required Unity Catalog / SQL warehouse / secrets configuration as app resources (not hard-coded IDs).
3. For more advanced customers, provide an optional bundle-based deployment (one YAML + databricks bundle deploy).
4. Inside their account, recommend:
   • CAN_USE for most users, CAN_MANAGE for app owners only.
   • “Anyone in my organization can use” if they want a centrally visible app.

[smithsonian]

Thank you for your comprehensive response. Worthy of a blog.