You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Any template which uses [Worker environment variables](/workers/configuration/environment-variables/), [secrets](/workers/configuration/secrets/), or [Secrets Store secrets](/secrets-store/) can now be deployed using a [Deploy to Cloudflare button](/workers/platform/deploy-buttons/).
12
+
13
+
Define environment variables and secrets store bindings in your Wrangler configuration file as normal:
14
+
15
+
<WranglerConfig>
16
+
```json
17
+
{
18
+
"name": "my-worker",
19
+
"main": "./src/index.ts",
20
+
"compatibility_date": "$today",
21
+
"vars": {
22
+
"API_HOST": "https://example.com",
23
+
},
24
+
"secrets_store_secrets": [
25
+
{
26
+
"binding": "API_KEY",
27
+
"store_id": "demo",
28
+
"secret_name": "api-key"
29
+
}
30
+
]
31
+
}
32
+
```
33
+
</WranglerConfig>
34
+
35
+
Add secrets to a `.dev.vars.example` or `.env.example` file:
36
+
37
+
```ini title=".dev.vars.example"
38
+
COOKIE_SIGNING_KEY=my-secret # comment
39
+
```
40
+
41
+
And optionally, you can add a description for these bindings in your template's `package.json` to help users understand how to configure each value:
42
+
43
+
```json title="package.json"
44
+
{
45
+
"name": "my-worker",
46
+
"private": true,
47
+
"cloudflare": {
48
+
"bindings": {
49
+
"API_KEY": {
50
+
"description": "Select your company's API key for connecting to the example service."
51
+
},
52
+
"COOKIE_SIGNING_KEY": {
53
+
"description": "Generate a random string using `openssl rand -hex 32`."
54
+
}
55
+
}
56
+
}
57
+
}
58
+
```
59
+
60
+
These secrets and environment variables will be presented to users in the dashboard as they deploy this template, allowing them to configure each value. Additional information about creating templates and Deploy to Cloudflare buttons can be found in [our documentation](/workers/platform/deploy-buttons/).
If you're building a Workers application and would like to share it with other developers, you can embed a Deploy to Cloudflare button in your README, blog post, or documentation to enable others to quickly deploy your application on their own Cloudflare account. Deploy to Cloudflare buttons eliminate the need for complex setup, allowing developers to get started with your public GitHub or GitLab repository in just a few clicks.
13
14
14
15
[](https://deploy.workers.cloudflare.com/?url=https://github.com/cloudflare/templates/tree/main/saas-admin-template)
15
16
16
17
## What are Deploy to Cloudflare buttons?
18
+
17
19
Deploy to Cloudflare buttons simplify the deployment of a Workers application by enabling Cloudflare to:
18
-
***Clone a Git repository**: Cloudflare clones your source repository into the user's GitHub/GitLab account where they can continue development after deploying.
19
-
***Configure a project**: Your users can customize key details such as repository name, Worker name, and required resource names in a single setup page with customizations reflected in the newly created Git repository.
20
-
***Build & deploy**: Cloudflare builds the application using [Workers Builds](/workers/ci-cd/builds) and deploys it to the Cloudflare network. Any required resources are automatically provisioned and bound to the Worker without additional setup.
20
+
21
+
-**Clone a Git repository**: Cloudflare clones your source repository into the user's GitHub/GitLab account where they can continue development after deploying.
22
+
-**Configure a project**: Your users can customize key details such as repository name, Worker name, and required resource names in a single setup page with customizations reflected in the newly created Git repository.
23
+
-**Build & deploy**: Cloudflare builds the application using [Workers Builds](/workers/ci-cd/builds) and deploys it to the Cloudflare network. Any required resources are automatically provisioned and bound to the Worker without additional setup.
21
24
22
25
23
26
24
27
## How to Set Up Deploy to Cloudflare buttons
25
-
Deploy to Cloudflare buttons can be embedded anywhere developers might want to launch your project. To add a Deploy to Cloudflare button, copy the following snippet and replace the Git repository URL with your project's URL. You can also optionally specify a subdirectory.
26
28
29
+
Deploy to Cloudflare buttons can be embedded anywhere developers might want to launch your project. To add a Deploy to Cloudflare button, copy the following snippet and replace the Git repository URL with your project's URL. You can also optionally specify a subdirectory.
27
30
28
31
<TabssyncKey="DeployButtonSnippet">
29
32
<TabItemlabel="Markdown">
@@ -52,35 +55,101 @@ If you have already deployed your application using Workers Builds, you can gene
52
55
53
56
Once you have your snippet, you can paste this wherever you would like your button to be displayed.
54
57
55
-
## Automatic Resource provisioning
58
+
## Automatic resource provisioning
59
+
56
60
If your Worker application requires Cloudflare resources, they will be automatically provisioned as part of the deployment. Currently, supported resources include:
***Compute**: [Durable Objects](/durable-objects/), [Workers AI](/workers-ai/), and [Queues](/queues/)
61
+
62
+
-**Storage**: [KV namespaces](/kv/), [D1 databases](/d1/), [R2 buckets](/r2/), [Hyperdrive](/hyperdrive/), [Vectorize databases](/vectorize/), and [Secrets Store Secrets](/secrets-store/)
63
+
-**Compute**: [Durable Objects](/durable-objects/), [Workers AI](/workers-ai/), and [Queues](/queues/)
59
64
60
65
Cloudflare will read the Wrangler configuration file of your source repo to determine resource requirements for your application. During deployment, Cloudflare will provision any necessary resources and update the Wrangler configuration where applicable for newly created resources (e.g. database IDs and namespace IDs). To ensure successful deployment, please make sure your source repository includes default values for resource names, resource IDs and any other properties for each binding.
61
66
67
+
### Worker environment variables and secrets
68
+
69
+
[Worker environment variables](/workers/configuration/environment-variables/) can be defined in your Wrangler configuration file as normal:
70
+
71
+
<WranglerConfig>
72
+
```json
73
+
{
74
+
"name": "my-worker",
75
+
"main": "./src/index.ts",
76
+
"compatibility_date": "$today",
77
+
"vars": {
78
+
"API_HOST": "https://example.com",
79
+
},
80
+
}
81
+
```
82
+
</WranglerConfig>
83
+
84
+
[Worker secrets](/workers/configuration/secrets/) can be defined in a `.dev.vars.example` or `.env.example` file with a [dotenv](https://www.npmjs.com/package/dotenv) format:
85
+
86
+
```ini title=".dev.vars.example"
87
+
COOKIE_SIGNING_KEY=my-secret # comment
88
+
```
89
+
90
+
[Secrets Store](/secrets-store/) secrets can be configured in the Wrangler configuration file as normal:
91
+
92
+
<WranglerConfig>
93
+
```json
94
+
{
95
+
"name": "my-worker",
96
+
"main": "./src/index.ts",
97
+
"compatibility_date": "$today",
98
+
"secrets_store_secrets": [
99
+
{
100
+
"binding": "API_KEY",
101
+
"store_id": "demo",
102
+
"secret_name": "api-key"
103
+
}
104
+
]
105
+
}
106
+
```
107
+
</WranglerConfig>
108
+
62
109
## Best practices
63
-
**Configuring Build/Deploy commands**: If you are using custom `build` and `deploy` scripts in your package.json (for example, if using a full stack framework or running D1 migrations), Cloudflare will automatically detect and pre-populate the build and deploy fields. Users can choose to modify or accept the custom commands during deployment configuration.
110
+
111
+
**Configuring Build/Deploy commands**: If you are using custom `build` and `deploy` scripts in your `package.json` (for example, if using a full stack framework or running D1 migrations), Cloudflare will automatically detect and pre-populate the build and deploy fields. Users can choose to modify or accept the custom commands during deployment configuration.
64
112
65
113
If no `deploy` script is specified, Cloudflare will preconfigure `npx wrangler deploy` by default. If no `build` script is specified, Cloudflare will leave this field blank.
66
114
67
115
**Running D1 Migrations**: If you would like to run migrations as part of your setup, you can specify this in your `package.json` by running your migrations as part of your `deploy` script. The migration command should reference the binding name rather than the database name to ensure migrations are successful when users specify a database name that is different from that of your source repository. The following is an example of how you can set up the scripts section of your `package.json`:
68
116
69
117
```json
70
118
{
71
-
"scripts": {
72
-
"build": "astro build",
73
-
"deploy": "npm run db:migrations:apply && wrangler deploy",
**Provide a description for bindings**: If you wish to provide additional information about bindings, such as why they are required in this template, or suggestions for how to configure a value, you can provide a description in your `package.json`. This can be particularly useful for environment variables and secrets where users might need to use a find a value outside of Cloudflare.
128
+
129
+
Inline markdown `` `code` ``, `**bold**`, `__italics__` and `[links](https://example.com)` are supported.
130
+
131
+
```json title="package.json"
132
+
{
133
+
"name": "my-worker",
134
+
"private": true,
135
+
"cloudflare": {
136
+
"bindings": {
137
+
"API_KEY": {
138
+
"description": "Select your company's [API key](https://example.com/) for connecting to the example service."
139
+
},
140
+
"COOKIE_SIGNING_KEY": {
141
+
"description": "Generate a random string using `openssl rand -hex 32`."
142
+
}
143
+
}
144
+
}
76
145
}
77
146
```
78
147
79
148
## Limitations
80
149
81
-
***Monorepos**: Cloudflare does not fully support monorepos
82
-
* If your repository URL contains a subdirectory, your application must be fully isolated within that subdirectory, including any dependencies. Otherwise, the build will fail. Cloudflare treats this subdirectory as the root of the new repository created as part of the deploy process.
83
-
* Additionally, if you have a monorepo that contains multiple Workers applications, they will not be deployed together. You must configure a separate Deploy to Cloudflare button for each application. The user will manually create a distinct Workers application for each subdirectory.
84
-
***Pages applications**: Deploy to Cloudflare buttons only support Workers applications.
85
-
***Non-GitHub/GitLab repositories**: Source repositories from anything other than github.com and gitlab.com are not supported. Self-hosted versions of GitHub and GitLab are also not supported.
86
-
***Private repositories**: Repositories must be public in order for others to successfully use your Deploy to Cloudflare button.
150
+
-**Monorepos**: Cloudflare does not fully support monorepos
151
+
- If your repository URL contains a subdirectory, your application must be fully isolated within that subdirectory, including any dependencies. Otherwise, the build will fail. Cloudflare treats this subdirectory as the root of the new repository created as part of the deploy process.
152
+
- Additionally, if you have a monorepo that contains multiple Workers applications, they will not be deployed together. You must configure a separate Deploy to Cloudflare button for each application. The user will manually create a distinct Workers application for each subdirectory.
153
+
-**Pages applications**: Deploy to Cloudflare buttons only support Workers applications.
154
+
-**Non-GitHub/GitLab repositories**: Source repositories from anything other than github.com and gitlab.com are not supported. Self-hosted versions of GitHub and GitLab are also not supported.
155
+
-**Private repositories**: Repositories must be public in order for others to successfully use your Deploy to Cloudflare button.
0 commit comments