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 410% smaller? 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,866 MB → 32.4 MB -98.9% | 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 |
Yes — it even shrinks already-compressed archives
The obvious objection: diffing should fail on ZIPs and JARs — they're already compressed.
It would, on random data. But versioned archives aren't random.
Version to version, the same JAR signatures land in the same order,
the same manifest.mf, the same icons, the same bundled
CSS. The bytes repeat — so the delta against the previous version
is tiny.
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.
Freeze writes during the window with
quota_bytes: 0.
Cutover
Cut over your apps' S3 endpoint to DeltaGlider. Your SDKs don't change.
Replicate
Run replication rules to mirror new writes to a DR region if you need one.