Deployment
Launch your website with production configuration, Cloudflare resources, a production domain, business flow verification, and subsequent updates.
Earlier chapters covered signing up for services, creating a project, developing business features, and configuring functionality. This chapter brings those steps together into a complete release: confirm the deployment target, prepare production configuration, publish code and data, and verify real business flows on your production domain.
If you have already deployed to workers.dev by following Initial deployment, you can prepare production configuration and run an update without recreating Cloudflare resources. If you followed the WebpageToPDF tutorial, first deploy any business dependencies you added, such as the PDF Worker.
What this chapter covers
Deployment is organized into six tasks. Pre-launch checks are part of production configuration and release verification. Third-party callbacks are covered alongside the domain switch, and the final article covers post-release monitoring and troubleshooting.
| Order | Article | Questions it answers |
|---|---|---|
| 1 | Confirm the deployment environment and Cloudflare resources | What accounts, Workers, D1, KV, R2, and Queues are, and which resources the scripts create |
| 2 | Prepare production configuration and secrets | Which settings to replace before launch and how to synchronize environment variables |
| 3 | Manage production databases and content | How database initialization, incremental migrations, backups, and documentation synchronization work together |
| 4 | Initial deployment and subsequent updates | Which command to use, what order it runs in, and how to handle interruptions |
| 5 | Production domains and third-party callbacks | How to change the site URL and update sign-in, payment, Turnstile, and email configuration |
| 6 | Launch verification and routine maintenance | How to verify critical flows, monitor background jobs, and handle release failures |
Start from your current state
| Current state | Next step |
|---|---|
| You have only a local project, with no remote resources yet | Prepare production configuration, then run npm run deploy:init |
Your site is already accessible on workers.dev | Check resources and configuration, then prepare to connect a production domain |
| Your site is deployed with a production domain | After changing code or production configuration, run npm run deploy:update |
| The previous command failed partway through | Identify the failed stage and check remote state, then follow Recovering from an interrupted deployment |
Initial deployment, updates, and domain changes use distinct commands with different prerequisites, resource changes, and execution orders. The following articles explain each separately.
Run all commands in this chapter from the root of the application you created with Saavo. Examples use https://app.example.com as the production URL. Replace it with your own domain. Commands that affect remote resources are identified explicitly. Keep local debugging separate from production operations.
Deployment completion and public launch
A successful deployment message in the terminal means the script has completed its build, publishing, and checks. You still need to verify through real flows that signup emails arrive, users receive entitlements after payment, and business tasks complete successfully.
We recommend first verifying functionality in a test environment, then deploying production configuration, and finally working through the verification checklist before opening registration and accepting payments. For subsequent updates, you can use the same steps to check affected features.