Deploys

Review the target, then let Goribu build and publish your Worker and static assets.

Cloudflare setup

Use a Cloudflare account and choose a Worker name in goribu.config.js. Deploying to an existing name updates that Worker, so use the name intended for this app.

Wrangler is bundled with Goribu. Log in from the app directory:

pnpm --dir node_modules/goribu exec wrangler login

For non-interactive environments, supply CLOUDFLARE_API_TOKEN. Set CLOUDFLARE_ACCOUNT_ID when the credentials can reach multiple accounts. Permissions must cover the Worker and any D1 or KV resources you declare.

Deploy validates credentials and account selection before building. Local development and pnpm build do not need Cloudflare authentication.

Preflight checks

pnpm typecheck
pnpm build
pnpm check

Skip typecheck in a JavaScript app. Build compiles the application and reports static output. Check reads the production plan without modifying resources.

The plan includes the Worker name, resource names and bindings, whether resources will be created or reused, migration status, and the intended production-secrets source. It does not print secret values.

A bare app with no resources may not need Cloudflare access for check; a successful check is not proof of deploy permissions. Deployment performs its own authentication preflight.

Deploy

pnpm run deploy

Use run: bare pnpm deploy is a different pnpm command. Goribu's deploy takes no extra arguments.

The command builds again, provisions declared resources, applies pending D1 migrations, and uploads the Worker and static assets. Wrangler prints the public URL. This changes production; it is not a preview command.

Run the same command for later releases. Verify the deployed URL, the important forms, and any new database behavior after publishing.

Provisioning

After configuration, authentication, build, and any secrets-file validation succeed, Goribu prepares resources:

• Create the named D1 database if missing, or reuse the existing one.
• Apply an explicit D1 replication setting, leaving existing policy unchanged when omitted.
• Create or reuse the exact named KV namespace.
• Add the resolved IDs to generated production bindings.
• Verify D1 migration history and apply pending files before Worker upload.

Ambiguous resource matches fail rather than choosing one. Undeclared resources are skipped. A KV-only app has no migration step.

Deploying new code does not erase database or KV data. Renaming a declaration selects another resource; removing it does not delete the old resource. Local data is never copied to production automatically.

Production secrets

When .env.production exists, a Wrangler dry run validates it and the built Worker before provisioning or migrations. Deployment uploads its keys as Worker secrets and preserves other existing secrets.

Without the file, existing platform secrets remain in use. Local .env is not a fallback. Read Configuration for the distinction between server secrets and public browser values.

Schema changes

Migrations run before the new Worker is uploaded, while the old Worker may still serve traffic. Keep the schema compatible with that old version.

Use an expand-and-contract sequence: add new tables or nullable columns first, deploy code that uses them, stop using the old shape in a later release, then remove it. Do not ship both an additive change and its destructive cleanup as simultaneously pending migrations.

For deliberate earlier schema changes, run pnpm exec goribu migrate --remote. Deploy will still verify history and apply anything else pending. There is no --no-migrations flag.

A failed migration stops the new Worker upload. Resources already created and earlier migration files already applied can remain; the whole deployment is not a transaction. See D1 migrations.

If deployment fails

Read the first error and repair that stage: configuration, authentication, build, secrets, provisioning, migration, or upload. A failed or interrupted command exits non-zero and does not report a successful deployment.

Keep generated dist/, .goribu/, .wrangler/, and goribu.wrangler.jsonc out of manual edits. They describe the build, not a second place to configure the app.