Databricks has compute scoped libraries, available to every notebook and job on a compute resource, and notebook scoped libraries, limited to one session. Both can pull from public repositories. Which one is used also depends on precedence, so a notebook install can override what your platform team approved.
The scopes
The Databricks documentation describes:
- Compute scoped libraries, installed on a compute resource and available to all its notebooks and jobs. Python, JAR and R are supported.
- Notebook scoped libraries, for Python and R only, creating an environment for one notebook session. They do not affect other notebooks on the same compute and do not persist, so they are reinstalled each session.
- Workspace libraries, which the docs describe as deprecated and not to be used. Storing libraries as workspace files is a separate, supported approach.
Where libraries can come from
Compute scoped libraries can come from package repositories such as PyPI, Maven or CRAN, from workspace files, from Unity Catalog volumes, from cloud object storage, or from a path on a local machine.
Precedence
From the docs, highest to lowest: notebook scoped libraries, then compute scoped libraries, then libraries in the Databricks Runtime. So a user running a notebook install can shadow the version your team pinned on the compute.
Controls the docs mention
| Control | Detail |
|---|---|
| Standard access mode | Recommended for all workloads; use dedicated mode only if you need functionality standard lacks |
| Service principal for jobs | Scheduled jobs on standard mode should run as a service principal |
| Volumes with Unity Catalog | On Runtime 13.3 LTS and above, install from volumes; users need read access |
| Allowlist | Admins add Maven coordinates and JAR paths to an allowlist for standard mode |
| DBFS root | Any workspace user can modify files there, so using it for libraries is deprecated and off by default from Runtime 15.1 |
| Installer identity | On standard mode, installs from workspace files or volumes use the installing user's identity |
A short policy
- Keep approved libraries in a volume that only your platform group can write to.
- Pin versions in compute configuration.
- Decide whether notebook installs are allowed on shared compute. They override by design.
- Use the allowlist for JARs and Maven coordinates.
- Run jobs as service principals with narrow rights.
- Do not store libraries in the DBFS root, where any workspace user can change them.
- Inventory what runs. Capture the installed package list from job runs, and scan it. See a data stack inventory checklist.
For secrets in the same environment see Databricks secret scopes and redaction limits.
Quick check
Can a notebook install override the compute library version?
According to the precedence order in the docs, notebook scoped libraries rank above compute scoped ones.
Why avoid the DBFS root for libraries?
The docs say any workspace user can modify library files stored there.
Safeguard dependency scanning can check an exported package list against known advisories, and asset discovery helps find where things run. A free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
