Stop paying AWS to store the same JAR a thousand times.
Your CI pipeline ships a new build every commit. Most of those builds share 99% of their bytes with the previous one. DeltaGlider stores the 1% and reconstructs the rest. Same S3 API. Same SDKs. Same workflow.
In progress: ReadonlyREST's build catalog → Hetzner
Beshu Tech is migrating its own ReadonlyREST build catalog off AWS S3 to Hetzner via DeltaGlider.
Why is 1.38.0 only 4.1× compression? Because the legacy deltaspace mixes ES 6, 7, and 8 Kibana plugins — structurally dissimilar artifacts in one prefix. The Delta Efficiency Panel correctly classifies it as "Fair, near Poor." We'd rather tell you that than gloss over it.
Latest Test Runs
| Version | Size (Encrypted) | Verdict |
|---|---|---|
| 1.69.0 | 2.8 GB → 32 MB -98.8% | Excellent |
| 1.38.0 | 13.7 GB → 3.3 GB -75.6% | Fair (cross-major ES range) |
| 1.17.1 | 26 MB → 6.8 MB -74.0% | Small dataset, dominated by reference |
| Full migration | 1.71 TB → TBD | In progress |
Why xdelta3 works on ZIP files
Skeptical question: xdelta3 should fail on compressed input.
It would, on random-compressed data. Versioned archives aren't
random — they're repetition machines. Same JAR signatures in the
same order, same manifest.mf, same icons, same bundled
CSS. The compression boundary moves but the underlying byte runs
repeat.
What a migration looks like
Deploy
Run DeltaGlider in your VPC. Point it at your existing AWS bucket — or a new Hetzner / Backblaze / Cloudflare bucket — anything S3-compatible.
Scan
Use the Delta Efficiency Panel to scan a sample prefix. Verify compression is in the range that justifies migration.
Stage
Stage migration bucket-by-bucket using per-bucket aliases
and quota=0 freeze mode during the window.
Cutover
Cut over your apps' S3 endpoint to DeltaGlider. Your SDKs remain completely unchanged.
Replicate
Run replication rules to mirror new writes to a DR region if you need one.