05. Bind Domains and Environment Variables

此内容尚不支持你的语言。

This chapter is where your deployment starts looking like a real online product instead of a set of temporary project URLs.

1. Recommended domain planning

Before binding anything, decide on a clear naming strategy.

Typical examples:

Keep the naming predictable so your team immediately knows which app each domain serves.

For backend Workers, use a consistent naming pattern if you plan to expose public service endpoints.

The exact shape can vary, but consistency matters more than creativity.

Bind the real domains for:

After binding, confirm the DNS state is healthy and the generated Cloudflare routes are actually active.

If your production architecture uses direct Worker domains, bind them now as well.

Make sure each Worker route or custom domain matches the URLs that the frontend will call.

Once domains are known, update the frontend apps to point at the real online services.

The web project should typically be updated with:

The admin app should also be switched from temporary or local values to the correct production endpoints.

Changing environment variables is not enough by itself.

After you finish those updates:

That ensures the new production URLs are actually baked into the running build.

Run a quick end-to-end check:

Can you open the public site?
Can you open the admin?
Does login point at the correct domain?
Do frontend requests target the real production APIs instead of old temporary URLs?

If any answer is no, stop here and fix it before initialization.