02. Prepare Cloudflare Resources
This chapter is about preparing the empty infrastructure in Cloudflare before you push real code.
0. How this chapter relates to the Dev Console
Section titled “0. How this chapter relates to the Dev Console”You can absolutely keep the Dev Console open while doing this chapter.
It is useful for:
- Reviewing the required services
- Checking what has already been created
- Keeping the deployment order visible
But the actual resource creation still needs to be treated as an infrastructure step.
1. Why you create “empty Workers” first
Section titled “1. Why you create “empty Workers” first”The first time you deploy this template, many service bindings already point at fixed Worker names.
That means the platform expects those target Workers to exist.
If they do not exist yet, you will hit errors like:
- binding target not found
- service not found
Creating the Workers first, even before real code deployment, prevents those binding failures.
2. Create the 10 empty Workers first
Section titled “2. Create the 10 empty Workers first”Create these Worker names in Cloudflare before deploying real code.
Required Worker name list
Section titled “Required Worker name list”zship-node1-authzship-node2-supportzship-node3-payzship-node4-notifyzship-node5-blogzship-node6-cdnzship-node7-sitezship-node8-promptzship-node9-checkinzship-node10-ai
The key point is simple:
- Use the repository defaults on the first pass
- Do not rename them yet
3. Create D1 databases
Section titled “3. Create D1 databases”The template expects multiple D1 databases.
3.1 The simplest approach
Section titled “3.1 The simplest approach”Use the names defined by the repository and create them one by one with Wrangler.
Do not try to redesign naming on day one.
3.2 Run the commands one by one
Section titled “3.2 Run the commands one by one”From the repository root, use the project’s Wrangler configuration to create each database required by the services.
As you create them:
- Record the generated IDs
- Put those IDs back into the related
wrangler.jsoncorwrangler.tomlfiles if placeholders still exist
If your workflow uses the Dev Console to help inspect config, that is fine. But the final result must be:
- every required D1 exists
- every config file references the correct resource IDs
4. Create the KV namespace
Section titled “4. Create the KV namespace”The payment-related flow uses a KV namespace.
Create it before deployment and write its ID back into the related configuration.
Again, use the repository’s expected structure first. This is not the time to redesign resource naming.
5. Create the R2 bucket
Section titled “5. Create the R2 bucket”The CDN-related flow expects an R2 bucket.
Create that bucket and make sure the related Worker config references the correct bucket name or binding.
6. Check whether your config files still contain placeholders
Section titled “6. Check whether your config files still contain placeholders”After resources are created, search the repository configs for placeholder values.
You are looking for cases where a D1, KV, or R2 binding still points at:
- a fake ID
- a TODO marker
- an empty placeholder
Expected result
Section titled “Expected result”At the end of this check:
- the required Workers already exist
- D1 IDs are filled in
- KV IDs are filled in
- R2 bucket configuration is real
If search still finds placeholders
Section titled “If search still finds placeholders”Do not move on yet.
If you continue deploying with placeholders left in config, later steps will fail in ways that are much harder to debug.
7. Checklist before you leave this chapter
Section titled “7. Checklist before you leave this chapter”Make sure all of the following are true:
- All 10 required Workers already exist in Cloudflare
- Required D1 databases have been created
- The KV namespace has been created
- The R2 bucket has been created
- Relevant config files no longer contain fake placeholder IDs
If any one of those is still incomplete, fix it now before the first real deployment.