How deploys work

Every site has its own git repository. A push to the site’s branch builds a new version and puts it live if the build passes. Each version is kept, so any earlier one can go live again.

Pushing

The remote is on the Worker’s Settings tab under Build and git, in the form https://git.digize.com/<workspace id>/<site>.git. Git asks for a username and password: any username works, and a push token is the password. A new Worker comes with one token, shown once. Make more in Sites › Settings under Git and push tokens, each for one Worker and from 1 to 365 days, and revoke them there.

git remote add digize https://git.digize.com/ws_01JB8X4Q2M7KTW9C3N5RVHZ1DE/site-01jc5m2p8r4t6v8x0z2b4d6f8h.git
git push digize main

The git endpoint takes only git’s smart HTTP exchange (clone, fetch and push), up to 512 MiB per request.

From push to live

Queued. The push reaches the repository, and Digize checks it’s for the site’s branch (main unless you change it) and that Build on push is on. Pushes to other branches are kept but not built. The deployment gets the next version number.
Building. Digize reads the commit: your build settings, the package manager from the lockfile, the framework from package.json, and the resources your wrangler.jsonc declares, which it makes if they don’t exist yet. In a sandbox, it runs the install command, then the build command, and packs the output: your Worker bundled with wrangler deploy --dry-run and its static assets, or a static output directory. The package is stored as that version’s build.
Deploying. D1 migrations in the repository are applied to the site’s databases. Then the static assets and the Worker are uploaded with the site’s variables, secrets, bindings, compatibility settings and placement. Secrets are opened for this step only: the build never sees them.
Live. The new version answers the next request. The one before it is marked superseded, and resources the config no longer declares are deleted.

If any step fails, the deployment is failed, with the stage (build or deploy) and the first line of the error, and the version that was live stays live.

A deployment’s state is one of queued, building, deploying, live, failed or superseded. From the API, GET /api/v1/deployments and GET /api/v1/deployments/{id} read them.

Build logs

The deployment’s page shows its log while it’s printed: the plan the build chose, each command and its output, the resources made, the archive’s size and the upload. Open it during a build and it starts from the beginning. When the build ends, the whole log is stored with the deployment.

The Worker’s own console.log output is on its Logs tab, read from Workers Logs for the last few minutes (up to an hour), and from the API with GET /api/v1/sites/{site}/logs. Sites › Settings turns Workers Logs on or off and sets the share of requests sampled, for every Worker from its next deploy.

Deploy now, redeploy and roll back

Action	What it does	API
Deploy now	Builds the newest commit on the site’s branch, as a push would.	`POST /api/v1/sites/{site}/deployments`
Redeploy	Uploads the live version’s stored build again, to pick up changed variables, secrets or settings without building.	`POST /api/v1/deployments/{id}/redeploy`
Roll back	Puts an earlier version’s stored build live again.	`POST /api/v1/sites/{site}/rollback`

A redeploy or rollback doesn’t build: it uploads the stored build with the site’s current variables, secrets, bindings and settings. It makes any resource the stored build declared that’s gone, but leaves the schema of a D1 database that has migrations as it is: only a new, empty database is migrated. Durable Object migrations aren’t run backwards either.

Only one Deploy now, redeploy or rollback runs at a time for a site: another one answers 409 conflict until it finishes. A failed deployment can’t be redeployed or rolled back to.

What a build is billed as

Each build’s time counts as build minutes, and each request a site answers counts as a request, in the workspace’s usage. Pricing has the free amounts and rates.