Data & Analytics
A dbt private package can work in Cloud and fail on a GHES laptop
Diagnose dbt Fusion private package failures when local resolution points to public GitHub instead of GitHub Enterprise Server.
November 8, 2026
A dbt customer report describes dbt deps failing on a laptop while the same native private: package works in the dbt platform. In Fusion 2.0.8, local resolution used git@github.com even though the repository lived on GitHub Enterprise Server. The resulting permission error can send a team into a needless SSH-key investigation.
Diagnose the boundary
Read the host in the actual failed Git address before rotating credentials. dbt's package documentation says local native private packages use the system SSH configuration and provider value to construct a URL. Its documented github format targets github.com. Confirm that a direct git clone to the enterprise host works with the same account; then compare it with the address shown by dbt deps. A wrong host and a bad key need different fixes.
Decide the next safe change
The issue records an explicit git: SSH URL to the enterprise host as a local workaround. Test whether that package specification remains compatible with the Cloud job before standardizing on it; the report says it is not portable with Cloud's native private: behavior. Keep package revision pinned, document the local/Cloud difference and track a vendor fix. Avoid putting access tokens in packages.yml or build logs.
Evidence boundary
Customer issue reports Fusion 2.0.8 local resolution to github.com for a GHES-hosted private package. A git SSH URL is a local workaround but differs from Cloud native private-package configuration; fix status was not established.
Adovo’s view
A development environment is part of the delivery system, not a personal convenience. When Cloud and a laptop resolve the same package to different hosts, the configuration is not one contract. Make that divergence visible until the product can express the host directly.