The anatomy of a deploy for the curious.
Updated
Every file is uploaded to a bucket path that includes its SHA-256 hash:
cdn/orgs/{org_id}/assets/{sha256}/{filename}
Identical files across deployments share the same storage location. When Next.js rebuilds without changing a chunk, that chunk's URL stays the same and never has to be re-uploaded.
/manifest is called. Rows for every new asset are inserted with uploaded=False.CDNAsset rows referenced by the deployment have uploaded=True, confirmed by /uploaded pings after each PUT./activate was called and the deployment is serving traffic. At most one per organization at a time.Every CLI request sends X-API-Key: sk_.... The backend looks the key up by SHA-256 hash, verifies it's active and has admin or api.write permission, and attaches the organization to the request. Only that organization's deployments and assets are ever touched.
The CLI never receives bucket credentials. The backend uses its own credentials to pre-sign a PUT URL for each object key, scoped to a single upload, with a TTL of 300 seconds. The URL is useless for anything except uploading that exact file. If a URL is leaked, the worst case is an attacker can re-upload the same SHA-256 to the same path — which is a no-op.
Activation runs inside a database transaction:
activated_at timestamp set.If the transaction fails for any reason, nothing changes. There is no window where the organization has zero or two active deployments.
Next.js includes a content hash in every asset filename. A new build produces filenames like chunks/main-a8f2c1.js rather than overwriting chunks/main.js. Browsers and CDN edges never need to be told to re-fetch anything — the new HTML references new URLs that haven't been seen before.