How do ISVs prevent customers modifying a wheel deployed into their own Databricks workspace?

vamsi_simbus — Tue, 25 Aug 2026 11:49:30 GMT

We're an ISV. Our product is a DLT pipelines, batch jobs, a Databricks App, and MLflow
models — is installed into each customer's own Databricks workspace as a dedicated
deployment, using Asset Bundles with one target per customer. We maintain the code
centrally; customers never receive the repo. We're packaging it as a wheel and running
it via python_wheel_task.

What we need is integrity, not secrecy. We accept that a workspace admin can read the
code. What matters is that the code we shipped is the code that runs — so that when
results are wrong it's our bug, and when we report outcomes, they're attributable to our
logic rather than to a local change.

How are others handling this when the deployment lives in a workspace the customer
administers? Interested in what has worked in practice, and where you decided the extra
effort stopped being worth it.

Re: How do ISVs prevent customers modifying a wheel deployed into their own Databricks workspace?

balajij8 — Tue, 25 Aug 2026 13:16:29 GMT

@vamsi_simbus

You can stage the wheel & other files inside a Unity Catalog Volume governed by strict schema level RBAC. You can use a a dedicated Service Principal that owns the bundle resources (jobs, DLT pipelines, Databricks Apps etc). You can grant the SP write privileges while ensuring customer only has read access without WRITE VOLUME permissions. It isolates the artifact from local overrides or silent edits while keeping the code inspectable for security reviews and compliance audits.

You can also keep the code entirely outside the customer workspace by hosting the wheel in an external private package registry (AWS Code Artifact, Azure Artifacts or other private repository) if feasible. Databricks jobs pull the wheel dynamically at runtime over HTTPS using short-lived signed URLs or credentialed configurations. You need to manage credential refresh mechanisms and external repo availability etc in it. It is a viable approach especially if you operate that infrastructure.

You can deploy wheels into Workspace Files under strict Service Principal ownership via Asset Bundles if Unity Catalog is not used yet. Set directory level Workspace ACLs so the deployment folder is owned exclusively by the SP restricts standard write access. This is less rigid than UC volumes as admins hold broad override capabilities across workspace paths but it still prevents tampering compared to open workspace directories or legacy DBFS locations.

You can enforce CICD to avoid manual deployments saving most of the hassles and also monitor the code/volume logs to check for discrepancies.

topic Re: How do ISVs prevent customers modifying a wheel deployed into their own Databricks workspace? in Administration & Architecture

How do ISVs prevent customers modifying a wheel deployed into their own Databricks workspace?

Re: How do ISVs prevent customers modifying a wheel deployed into their own Databricks workspace?