03. Deploy Backend Workers

This chapter is about getting the backend online safely.

0. You can keep the Dev Console open

It is completely fine to keep the Dev Console open while doing this chapter.

It can help you:

• Check service names
• Review environment setup
• Cross-check deployment order

But the actual production deployment still needs to be executed carefully and in sequence.

1. Understand what is truly required first

Not every secret needs to be perfect on the first minute, but some values must be filled before the first working deployment.

What you must handle on the first pass

At minimum, fill the secrets and configuration required for:

• authentication
• core service-to-service communication
• any mandatory backend startup values

What to fill if you want real payments

Only after the core system works, continue with payment provider setup such as:

• Stripe-related keys
• Creem-related keys
• webhook secrets

What to fill if you want AI features

AI-related provider keys can also be added after the core system is proven working, unless your launch depends on AI immediately.

2. Fill the two critical secrets for node1-auth-service first

This service is one of the first pieces that must be correct, because login and later initialization depend on it.

Recommended approach

Start with the auth service first, verify it, then continue to the rest.

Do not try to fill every Worker secret for every optional feature before confirming the core path works.

What you need to fill

At minimum, make sure the key auth-related secrets and environment values used by node1-auth-service are present and correct.

If you are unsure, prefer:

• checking the service’s Wrangler config
• checking the Dev Console
• checking the .dev.vars or production secret workflow used by your team

3. If you need payments or AI, fill those too

Once the auth basics are done, continue with optional services only if your launch requires them.

Payment services

Fill the provider secrets and callback configuration used by the payment Worker.

Typical examples:

• API keys
• webhook secrets
• product or price IDs

AI services

Fill the provider keys and model-related configuration used by the AI Worker.

Typical examples:

• model provider API keys
• gateway settings
• model identifiers

4. Run remote database migrations first

Before deploying the full backend, run the remote database migrations.

Why:

• the Workers expect schemas and tables to exist
• deploying code before the schema is ready often causes confusing runtime failures

Treat remote migration as part of deployment, not an optional cleanup task.

5. Deploy the Workers one by one

After secrets and migrations are in place, deploy the Workers in sequence.

The safest first pass is:

1. confirm resources already exist
2. confirm required secrets are filled
3. run remote migrations
4. deploy Workers one at a time
5. verify logs and health after each important step

Why real code deployment is safe now

At this point:

• service binding targets already exist
• resource IDs should already be real
• the database schema should already exist

So the platform is finally ready for actual service code.

6. If deployment says a service binding cannot be found

This is one of the most common first-deploy problems.

Check 1: did you rename a Worker

If you changed the default Worker names, bindings will no longer match.

Check 2: were all 10 empty Workers actually created

Sometimes users create only the few Workers they noticed first.

That is not enough if some service bindings reference other Workers later in the graph.

Check 3: did you deploy into a different Cloudflare account

This also happens often:

• resources were created in account A
• Wrangler is logged into account B

From the app’s point of view, that looks exactly like missing resources.

7. Checklist before you leave this chapter

Before moving on, confirm:

• required auth secrets are filled
• optional payment and AI secrets are filled if needed
• remote database migrations have run successfully
• Workers have been deployed successfully
• no remaining binding-not-found errors are blocking startup

Once all of that is stable, you are ready for the frontend.