JitPack can be used with care, but it is a different trust model from a publisher uploading signed releases. It builds Git projects on demand, so you are trusting the repository's code and JitPack's build. Pin release tags or commits, never branch snapshots, and filter the repository to only the groups you need.
What JitPack does
Its documentation says JitPack builds Git projects on demand and provides ready-to-use artifacts such as jar and aar files. On the first request it checks out the code and builds it, and afterward it serves the artifacts.
Coordinates follow the host. For GitHub the group is com.github plus the username, the artifact is the repository name, and the version is a release tag, a commit hash or a branch snapshot. Other hosts use different group prefixes.
What the docs say about stability
| Version type | Behavior per JitPack docs | Reproducible? |
|---|---|---|
| Release tag | Published by creating a release | Frozen after 7 days |
| Commit hash | Builds that commit | Yes, once built |
| branch-SNAPSHOT | Builds the latest commit on a branch | No, can still get updates |
The docs state public artifacts become frozen after 7 days, and can be rebuilt during that window to fix release issues. They also say hosted artifacts stay available even if the source repository is deleted.
What the docs do not tell you
The pages we read do not describe checksums, signing or build provenance, and they link to a security FAQ we could not read. So we cannot confirm how builds are secured, and you should read that FAQ yourself before deciding. Compare that with what you require elsewhere: see what Maven Central requirements prove and do not.
Controls to apply if you use it
- Filter the repository. JitPack's own docs recommend filtering Gradle lookups for security and performance. Use a content filter so JitPack serves only the specific groups you chose, as in keeping private groups off public repos.
- Pin tags or commits. Never use a branch snapshot or a plus version in a shipped build.
- Verify. Use Gradle dependency verification so a later change to a jar is noticed.
- Review the source. The artifact is built from that Git project, so its maintainers and recent commits are your risk.
- Prefer the registry release if the project also publishes to a public repository you already trust.
- Track it. Record the dependency in your SBOM with its source so an advisory can be matched.
When to avoid it
If a build must be reproducible years later, or the project is a single maintainer fork with no release history, think twice. A fork pulled by commit hash is more predictable than a branch, but you still own the review.
Try it yourself
Click through it at your own pace, or open it full screen.
Find components with an unusual coordinate. These are the ones to review by hand.
Safeguard's dependency scanning and SBOM generation record where each component came from, and the free scan at gold.safeguard.sh/scan shows what a repository pulls in.
Quick check
Is a JitPack release tag immutable?
The docs say public artifacts become frozen after 7 days. Before that they can be rebuilt, so pin a commit hash for stronger repeatability.
Should I use branch-SNAPSHOT versions?
Not in shipped builds. The docs say snapshots might still get updates, so they suit development only.
Sources
Last reviewed: 19 October 2026.
