Local-first CI/CD artifact transfer optimization.
Vernier reduces repeated artifact transfer by sending only the delta between artifact versions, reconstructing the target artifact locally, and verifying the result with SHA-256.
It is designed for artifact-heavy CI/CD pipelines where runners repeatedly download similar artifacts between jobs, environments, registries, and deployment stages.
app-v2.jar (574 KB) → delta (30 KB) 94.9% less transfer
Docker layer (12.5 MB) → delta (185 KB) 98.6% less transfer
lib-v2.dll (30 KB) → delta (128 B) 99.6% less transfer
Works with JAR / WAR / ZIP, Docker layers, TAR.GZ, DLLs / shared libraries, and generic binary artifacts.
Local-first. Registry-friendly. SHA-256 verified. Safe fallback built in.
Looking for technical feedback from DevOps / CI/CD engineers working with artifact-heavy pipelines.
Try Vernier on two versions of the same artifact and open an Issue or Discussion with:
- artifact type
- delta size
- transfer reduction
- CI environment
- any integration friction
Pre-built evaluation binaries are available under GitHub Releases:
- Linux x64
- Windows x64
- SHA-256 checksums
Latest release:
https://github.com/shmul-dev/vernier/releases/latest
# Linux / WSL
chmod +x vernier
./vernier --help
# Windows
vernier-windows.exe --helpThis repository currently provides:
- documentation
- benchmark examples
- demo assets / screenshots
- pre-built evaluation binaries under Releases
The core engine source code is not public at this stage.
If you are looking for the executable, go to:
https://github.com/shmul-dev/vernier/releases/latest
Vernier is not a Java decompiler and does not inspect source code.
It does not use:
- CFR Decompiler
- JD-GUI
- JADX
- bytecode-to-source reconstruction
JAR is only a common example because a .jar file is a structured ZIP artifact.
Vernier works at the artifact level, not the source-code level:
old artifact + delta → reconstructed new artifact
It compares artifact versions, generates a compact .vrnz delta, reconstructs the target artifact locally, and verifies the result with SHA-256.
No Java source code is reconstructed. No bytecode is decompiled. No installed JAR is modified in place.
Modern CI/CD pipelines repeatedly transfer nearly identical artifacts.
A small change in a JAR, Docker layer, ZIP archive, or binary package often causes the entire artifact to be downloaded again.
Instead of transferring the full artifact:
app-v2.jar → 574 KB
Vernier can transfer only the delta:
patch.vrnz → 30 KB
Then the CI runner reconstructs the full target artifact locally and verifies the result.
Typical incremental results:
JAR / ZIP artifacts → 90–95% less transfer
Docker layers / TAR.GZ → up to 98% less transfer
Small binaries / DLLs → up to 99% less transfer
previous artifact
│
▼
vernier diff
│
▼
patch.vrnz
│
▼
transfer delta through existing registry / pipeline
│
▼
vernier patch
│
▼
reconstructed target artifact
│
▼
SHA-256 verify
The release model stays the same:
- immutable artifacts
- deterministic CI/CD
- existing registries
- existing runners
- no mandatory SaaS dependency
Vernier optimizes the transport path, not the artifact model.
If your binary includes the built-in demo command:
vernier demoThe demo runs a local benchmark and shows diff, patch, and verification behavior.
If you already have two artifact versions, use the normal flow below.
You need two versions of the same artifact:
app-v1.jar
app-v2.jar
They do not have to be Java files. They can be ZIPs, Docker/TAR layers, DLLs, shared libraries, or any binary artifact.
vernier diff -o app-v1.jar -m app-v2.jar -d patch.vrnzExample output:
✓ Delta created ✓ Output verified
Original: 1.77 MB
Delta: 133.59 KB
Saved: 92.6%
vernier patch -t app-v1.jar -d patch.vrnz -o app-v2-restored.jarExample output:
✓ Restored successfully ✓ SHA-256 verified — identical artifact
Full artifact: 1.77 MB
Delta used: 133.59 KB
Saved: 92.6%
vernier verify -f app-v2-restored.jar -d patch.vrnzExample output:
✓ Verified — file is authentic and unmodified
build produces app-v2.jar
vernier diff app-v1.jar → app-v2.jar → patch.vrnz
push artifact and/or delta to existing registry
previous version available locally?
YES → download patch.vrnz
→ reconstruct locally
→ verify SHA-256
NO → download full artifact
→ safe fallback
No registry replacement is required.
Vernier works alongside existing CI systems, artifact registries, and runners.
If delta transfer is not beneficial, Vernier falls back to full transfer.
⚠ SAFE MODE — delta >= file size, full snapshot used
This is normal on the first run, after a major version change, or when no previous baseline exists.
The design principle is simple:
Pipelines must continue normally.
Vernier is most effective when:
- artifacts change incrementally between builds
- CI runners repeatedly download similar artifacts
- distributed runners share common baselines
- Docker layers contain mostly stable content
- registry traffic or egress costs matter
- pipelines repeatedly move large archives
Less effective when:
- artifacts are completely regenerated every build
- compressed payloads change entirely between versions
- no previous artifact baseline exists locally
- the upstream system already deduplicates the same transfer path
| Format | Examples |
|---|---|
| ZIP containers | .jar, .war, .zip, .docx, .nupkg |
| TAR / TAR.GZ | .tar, .tar.gz, .tgz |
| Docker layers | OCI / TAR-based layers |
| Small binaries | .dll, .so, .exe |
| Generic binaries | arbitrary binary artifacts |
Format detection is automatic where supported.
Benchmark methodology:
- take an old artifact version
- take an updated artifact version
- compute delta
- reconstruct the target artifact
- verify SHA-256 integrity
- compare transfer sizes
Current public artifact benchmarks:
| Artifact | Versions | Result |
|---|---|---|
| spring-core | 6.1.0 → 6.1.1 | 92.6% less transfer |
| elasticsearch | 8.11.0 → 8.11.1 | 94.9% less transfer |
| jackson-databind | 2.16.0 → 2.16.1 | 90.4% less transfer |
All benchmark results are SHA-256 verified.
vernier server --port 8080
# open http://localhost:8080The local dashboard provides:
- transfer savings visibility
- reporting history
- ROI visibility
- multi-agent reporting
- operational confidence
The dashboard is local-first and designed for infrastructure teams. It is not a SaaS analytics platform.
By default, each machine keeps its own local reports.
To aggregate multiple agents into one dashboard:
# All other agents — run normally:
vernier server --port 8080
# Aggregating agent only:
export VERNIER_REPORTS_HOSTS="agent-2,agent-3,agent-4"
vernier server --port 8080Local reports remain visible even if remote agents are unreachable.
Remote fetches have a short timeout and do not block diff / patch operations.
| Variable | Description |
|---|---|
VERNIER_LICENSE_KEY |
Optional license key / paid entitlement |
VERNIER_SCOPE |
Pipeline or service grouping label |
VERNIER_REPORTS_HOSTS |
Aggregate multiple reporting agents |
VERNIER_NO_TELEMETRY=1 |
Disable optional external communication |
vernier demo
vernier diff -o <original> -m <modified> -d <delta>
vernier patch -t <target> -d <delta> -o <output>
vernier verify -f <file> -d <delta.vrnz>
vernier status
vernier server --port <port>
vernier snapshot --export <file.vrnz>
vernier report --from <file.vrnz>
Vernier is designed as local infrastructure tooling:
- artifacts remain inside your environment
- reconstruction is SHA-256 verified
- execution is deterministic
- safe fallback is built in
- no registry replacement is required
- no source code access is required
- no Java decompilation or reverse engineering is performed
Vernier includes a local evaluation model.
Execution commands remain operationally safe:
diffpatchverify- safe fallback
Paid plans are intended to unlock reporting visibility, deeper history, ROI reporting, and organizational reporting coverage.
Execution is not designed to become a CI risk.
Vernier is:
CI/CD artifact transfer optimization with operational reporting visibility.
Vernier is not:
- a Java decompiler
- a source-code diff tool
- a generic compression utility
- an observability platform
- an analytics SaaS
- a CI replacement
- an artifact registry replacement
Core message:
Transfer only what changed.
Verify the restored artifact.
Keep the pipeline safe.
For technical feedback, integration questions, or benchmark discussion:
- open a GitHub Issue: https://github.com/shmul-dev/vernier/issues
- open a GitHub Discussion: https://github.com/shmul-dev/vernier/discussions