Deploying one website to an edge runtime is straightforward. Deploying many independently configured sites from one repository requires stronger release discipline. The safest workflow validates the shared build once, then verifies each tenant's configuration before its Worker is updated.
1. Validate the shared application
Start with a clean production build. Type errors, missing server-only modules, or environment variables initialized during module import can break every tenant at once. External service clients should be created lazily so a build does not require credentials for features that are not being executed.
Run the production build in the same Node.js version used by the deployment platform. Confirm that dynamic routes use the current framework contract, including promised route parameters where required.
2. Validate tenant configuration
Before uploading a Worker, verify that the selected site record includes:
- a stable site ID;
- a valid HTTPS production domain;
- a unique Worker name;
- locale and timezone values;
- required feature flags;
- branding and SEO configuration;
- only the secrets needed by that tenant.
Reject ambiguous or missing site IDs. Deploying a default tenant by accident is more damaging than stopping the release.
3. Build the Worker bindings deliberately
Bindings are part of the application contract. Keep their names consistent across environments and avoid injecting unrelated secrets into every Worker. Separate public configuration from secret values, and verify that no server key is exposed through a client-prefixed environment variable.
4. Test the production artifact
Test the actual artifact, not only the development server. At minimum, check:
- The homepage returns a successful response.
- The site resolver selects the expected tenant.
- Canonical and Open Graph URLs use the custom domain.
- Knowledge-base and sitemap routes contain tenant-scoped content.
- Mobile pages have no horizontal overflow.
- Images load through the configured optimizer or asset origin.
- Admin and API routes reject unauthenticated requests.
5. Attach domains after a successful upload
Upload and validate the Worker before changing production routing. Domain attachment should be an explicit deployment step with its own status and error reporting. If the route operation fails, retain the successful Worker upload in the log but mark the complete deployment as failed.
6. Record enough data to roll back
Every deployment record should include the Git commit, Worker name, Cloudflare deployment identifier, domain list, timestamps, operator, and result. Rollback should select a known successful deployment rather than rebuilding an arbitrary historical branch.
7. Observe the first requests
After routing changes, check response status, latency, and error logs. Test both the apex and preferred hostname. Confirm redirects are intentional and that robots and sitemap routes remain accessible.
A checklist cannot remove every deployment risk, but it converts hidden assumptions into explicit gates. That is the foundation of reliable multi-site operations.