[michalsuba-e2b]

make copy-public-builds only handled PROVIDER=aws/gcp; azure fell through to the gcp else-branch and built a malformed gs://-fc-kernels/ path from the unset GCP_BUCKET_PREFIX.

Adds the azure arm: download from the same public GCS bucket (gcloud storage cp — avoids gsutil's Python version gate), upload via az storage blob upload-batch --auth-mode login into the fc-kernels/fc-versions/fc-busybox containers addressed by AZURE_STORAGE_ACCOUNT_NAME. Containers are unprefixed, unlike AWS/GCP's per-purpose-prefixed buckets — the BYOC Azure storage account already carries the unique prefix in its own name. The --auth-mode login data-plane call works because the BYOC terraform grants the apply runner Storage Blob Data Contributor on that account for exactly this flow.

Extracted unchanged from the 2026-06-Azure-PoC branch, where it has run end-to-end against live Azure BYOC environments. Consumed by e2b-dev/byoc via its submodule pin (companion byoc PR bumps it).

🤖 Generated with Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ All tests successful. No failed tests found.

📢 Thoughts on this report? Let us know!

[claude]

LGTM — straightforward addition of an azure arm to copy-public-builds, mirroring the existing aws branch pattern.

Extended reasoning...

Overview

The change is confined to a single Makefile target (copy-public-builds), adding an else ifeq ($(PROVIDER),azure) branch alongside the existing aws and gcp/default branches. It downloads the public kernel/firecracker/busybox artifacts from the shared public GCS bucket via gcloud storage cp, then uploads them into Azure Blob Storage containers via az storage blob upload-batch --auth-mode login, using the same mkdir/cleanup scaffolding already used by the aws branch.

Security risks

None of note. This is operator-invoked build tooling, not a request-serving code path. --auth-mode login relies on the invoking identity's existing Azure RBAC (Storage Blob Data Contributor per the PR description) rather than embedding credentials, and the GCS source bucket is the same public, already-trusted bucket the aws/gcp branches use. No user input, no secrets embedded in the diff.

Level of scrutiny

Low. This is a Makefile/build-tooling change, structurally identical to the pre-existing aws branch (mkdir temp dirs → cp from public bucket → upload to per-provider destination → rm temp dirs), just retargeted to Azure CLI commands. There's no business logic, no data model or security-boundary change, and it only affects a manual self-host/BYOC workflow rather than the production request path.

Other factors

The PR description states this was extracted unchanged from a branch that has run end-to-end against live Azure BYOC environments, and it's consumed by a companion e2b-dev/byoc submodule bump. The bug-hunting pass found no issues, and my own read of the diff didn't surface anything beyond the pattern already established by the aws branch. Given the small, self-contained, low-blast-radius nature of the change, this doesn't need human review.

[michalsuba-e2b]

Closing in favor of e2b-dev/belt#1330 — same diff, re-targeted per the belt-first process (development in e2b-dev/belt oss/infra, automation syncs to this repo).