Eazip Cloud
When to use Eazip Cloud
Move URL-based ZIP jobs beyond the limits and lifetime of a browser tab without changing your integration.
Local jobs are the default and cover everyday ZIP downloads. Use Eazip Cloud when the browser becomes the constraint.
What problems does Cloud solve?
Choose Cloud when at least one of these is true:
- the archive is multi-gigabyte or contains thousands of URLs;
- the job must continue across a reload;
- the browser cannot fetch a source because of CORS;
- archive bytes should not occupy tab memory; or
- a trusted backend should create the source list.
Remote URLs only
Cloud cannot read a browser File or Blob. Give it URLs that Eazip Cloud
can fetch, such as signed S3 or R2 URLs.
What changes from Local?
| Local | Cloud | |
|---|---|---|
| Runs in | The browser tab | Eazip Cloud |
| Sources | Files, blobs, and URLs | URLs |
| Progress | Browser ZIP progress | Session polling |
| Reload | Stops the job | Can reconnect to the session |
| Setup | None | Public key or backend-created session |
The package and UI stay the same:
zip.download({
strategy: 'cloud',
publicKey: 'pk_ez_...',
files: urls,
});createZip() and startZip() accept the same strategy when you use
@eazip/core.
What remains the same?
- the job lifecycle and result shape;
<EazipTray />in React;- partial output and multiple ZIP downloads;
maxZipSizeBytesfor splitting output; and- the path back to Local for smaller jobs.
Choose a Cloud setup
- Frontend-created session: get a public key and scope it with origins and source hosts.
- Backend-created session: keep the URL list and authorization on your server, then return a session handle to the SDK.
Account, billing, plan limits, and the HTTP API live in the Eazip Cloud product area.