Confirm the deployment environment and Cloudflare resources

Check the account, project state, and resource bindings, and distinguish initial setup from remote updates and local development.

Published Sep 20, 2026

Saavo production applications run on Cloudflare Workers, with separate resources for business data, files, content, and background jobs. Before deploying, confirm which account owns the resources and whether the project has already been initialized so that you can choose the correct command.

For Cloudflare signup and R2 activation steps, see Prepare Cloudflare. This article focuses on the relationship between your project and account.

1. Confirm the project you are working with

Check package.json and wrangler.jsonc in the application root to confirm that this is the business project you intend to launch. The current template provides these deployment commands:

npm run deploy:init
npm run deploy:update
npm run domain:set -- https://app.example.com

These commands are listed here for reference. For their execution order, see Initial deployment and subsequent updates. Do not use the Saavo website's own build scripts as deployment commands for a newly created application, or add a script named deploy:prod just because an older tutorial mentions it.

Next, identify the project's state:

Not initialized: Worker and resource names still need confirmation. Deployment has not yet written D1 database_id or KV id values.
Initialized: wrangler.jsonc records the account and resource IDs, and the corresponding Worker exists remotely.
Initialization interrupted: Some resources exist, but database migrations, KV synchronization, or health checks have not finished.

Investigate the third state before proceeding. Do not treat it as a project that has never been deployed.

2. Check the Cloudflare account

Run the following in your terminal:

npx wrangler whoami

If you are not signed in, run:

npx wrangler login

A single Cloudflare user may have access to multiple accounts. Check the account list in the whoami output and make sure the intended deployment account matches account_id in wrangler.jsonc.

During initial deployment, the script can let you choose an account and save it in the configuration. Subsequent updates check whether the current identity can access the recorded account. They do not automatically migrate the project to another account.

If you use a deployment machine or CI, store deployment credentials in that execution environment's credential configuration. These credentials authorize the publishing tools and are not application runtime variables. Do not put them in .env.production.

3. Understand the template's resources

Binding or configuration	Cloudflare resource	Purpose
Worker `name`	Worker	Handle page, API, queue, and scheduled requests
`DB`	D1	Users, orders, permissions, support tickets, and business data
`ANALYTICS_DB`	D1	Analytics data, separate from the main business database
`MAIN_KV`	KV Namespace	Documentation and blog content, plus other KV data used by the project
`MAIN_R2`	R2 Bucket	Object data such as uploaded files
`ASYNC_POLICY_TASK_QUEUE`	Queue	Reaction background business tasks
`ASYNC_LOGGER_QUEUE`	Queue	Asynchronous log writes
`ANALYTICS_QUEUE`	Queue	Analytics events
`durable_objects.bindings`	Durable Objects	Rate limiting, counting, nonces, token buckets, and timers
`triggers.crons`	Cron Triggers	Scheduled entitlement checks and data maintenance

The default configuration retains these resources. Even if your first release does not use a particular UI feature, do not delete a binding based only on its name. Related services and background entry points may still depend on it.

The DB and ANALYTICS_DB bindings must point to different D1 databases. Their schemas, maintenance tasks, and data purposes differ. Do not use the same ID for both to reduce configuration.

4. Let the initial deployment create resources

Use npm run deploy:init for a new project. The script first checks the target account and resource names. After confirmation, the deployment flow creates and binds the resources and records the generated identifiers in the project configuration.

You usually do not need to run a series of wrangler d1 create, kv namespace create, and queues create commands beforehand. If resources with the same names already exist, the initialization checks stop. They do not take over those resources by default.

The template's initial D1 and KV configuration has no production IDs that can be reused across accounts. Resource names are also adjusted to match the Worker name. For example, a Worker named my-app uses my-app-db as its main database name.

The account must have R2 access for initial deployment. If you are told that R2 is not enabled, follow the preparation steps before continuing. If permission checks fail, first verify the account and authorization. Do not change resource IDs to bypass the error.

Durable Object classes are registered during deployment through the migration configuration in wrangler.jsonc. You do not need to create object instances manually. Do not casually rename or roll back migration tags that have already been deployed.

5. Check bindings for an existing project

After the initial deployment, run:

npm run doctor:remote

This checks the production environment file, binding configuration, migration files, and current Cloudflare identity. An ERROR fails the check. Assess each WARNING against the features you have enabled. For example, missing Stripe configuration may be expected if the first release does not accept payments.

The doctor:remote command is not a complete check of live business flows, nor does it verify email, payments, or the data in every resource individually. After it passes, check the Worker's bindings in Cloudflare and verify business flows as described in the following articles.

We recommend keeping a deployment record that includes:

The code commit or release version.
The Cloudflare account and Worker name.
The mappings for the main database, analytics database, KV, R2, and Queues.
The production domain, latest deployment time, and command used.

Resource IDs stay in the project configuration to support subsequent updates. Manage secrets separately, and do not paste complete secrets into deployment records.

6. Local development, production, and additional business services

The database state used by local npm run dev is separate from remote D1 data. It is normal for local test accounts to be absent after deployment. Do not overwrite production with the entire local test database because of this.

The .env.production file contains the production configuration used when deploying the current project. It does not mean that the template automatically provides a Wrangler environment named production. The default flow uses the project's top-level resource configuration and does not require an additional --env production flag.

If you need a separate preview environment, explicitly prepare its own Worker, resource bindings, domain, and provider test configuration. Copying an environment file alone does not isolate databases or queues.

The PDF Worker from the tutorial is an additional business dependency. The general deployment script does not publish it automatically. Deploy services like this before launch, then check the main site's Service Binding, credentials, and calling contract. The dependencies your product needs depend on your own implementation.

Next: Prepare production configuration and secrets.