Cloudflare Queues bindings spec

This output binding for Dapr allows interacting with to publish new messages. It is currently not possible to consume messages from a Queue using Dapr.

To setup a Cloudflare Queues binding, create a component of type . See this guide on how to create and apply a binding configuration.

Warning

The above example uses secrets as plain strings. It is recommended to use a secret store for the secrets as described here.

Spec metadata fields

This component supports output binding with the following operations:

  • publish (alias: create): Publish a message to the Queue.
    The data passed to the binding is used as-is for the body of the message published to the Queue.
    This operation does not accept any metadata property.

Create a Cloudflare Queue

To use this component, you must have a Cloudflare Queue created in your Cloudflare account.

You can create a new Queue in one of two ways:

  • Using the Cloudflare dashboard

  • Using the :

    1. # Authenticate if needed with `npx wrangler login` first
    2. npx wrangler queues create <NAME>
    3. # For example: `npx wrangler queues create myqueue`

Dapr can manage the Worker for you automatically, or you can pre-provision a Worker yourself. Pre-provisioning the Worker is the only supported option when running on .

Important

Use a separate Worker for each Dapr component. Do not use the same Worker script for different Cloudflare Queues bindings, and do not use the same Worker script for different Cloudflare components in Dapr (for example, the Workers KV state store and the Queues binding).

If you want to let Dapr manage the Worker for you, you will need to provide these 3 metadata options:

  • : Name of the Worker script. This will be the first part of the URL of your Worker. For example, if the “workers.dev” domain configured for your Cloudflare account is mydomain.workers.dev and you set workerName to mydaprqueue, the Worker that Dapr deploys will be available at https://mydaprqueue.mydomain.workers.dev.
  • cfAccountID: ID of your Cloudflare account. You can find this in your browser’s URL bar after logging into the Cloudflare dashboard, with the ID being the hex string right after dash.cloudflare.com. For example, if the URL is https://dash.cloudflare.com/456789abcdef8b5588f3d134f74acdef, the value for cfAccountID is 456789abcdef8b5588f3d134f74acdef.
  • cfAPIToken: API token with permission to create and edit Workers. You can create it from the in the “My Profile” section in the Cloudflare dashboard:
    1. Click on “Create token”.
    2. Select the “Edit Cloudflare Workers” template.
    3. Follow the on-screen instructions to generate a new API token.

When Dapr is configured to manage the Worker for you, when a Dapr Runtime is started it checks that the Worker exists and it’s up-to-date. If the Worker doesn’t exist, or if it’s using an outdated version, Dapr creates or upgrades it for you automatically.

If you’d rather not give Dapr permissions to deploy Worker scripts for you, you can manually provision a Worker for Dapr to use. Note that if you have multiple Dapr components that interact with Cloudflare services via a Worker, you will need to create a separate Worker for each one of them.

To manually provision a Worker script, you will need to have Node.js installed on your local machine.

  1. Create a new folder where you’ll place the source code of the Worker, for example: daprworker.
  2. If you haven’t already, authenticate with Wrangler (the Cloudflare Workers CLI) using: npx wrangler login.
  3. Inside the newly-created folder, create a new wrangler.toml file with the contents below, filling in the missing information as appropriate:
  1. Copy the (pre-compiled and minified) code of the Worker in the worker.js file. You can do that with this command:
  1. # Set this to the version of Dapr that you're using
  2. DAPR_VERSION="release-1.10"
  1. Deploy the Worker using Wrangler:

Once your Worker has been deployed, you will need to initialize the component with these two metadata options:

  • workerName: Name of the Worker script. This is the value you set in the name property in the wrangler.toml file.

Generate an Ed25519 key pair

All Cloudflare Workers listen on the public Internet, so Dapr needs to use additional authentication and data protection measures to ensure that no other person or application can communicate with your Worker (and thus, with your Cloudflare Queue). These include industry-standard measures such as:

  • All requests made by Dapr to the Worker are authenticated via a bearer token (technically, a JWT) which is signed with an Ed25519 key.
  • All communications between Dapr and your Worker happen over an encrypted connection, using TLS (HTTPS).
  • The bearer token is generated on each request and is valid for a brief period of time only (currently, one minute).

You can generate a new Ed25519 key pair with OpenSSL using:

  1. openssl genpkey -algorithm ed25519 -out private.pem
  2. openssl pkey -in private.pem -pubout -out public.pem

If you don’t have the step CLI already, install it following the .

Next, you can generate a new Ed25519 key pair with the step CLI using:

  1. step crypto keypair \
  2.   public.pem private.pem \
  3.   --kty OKP --curve Ed25519 \
  4.   --insecure --no-password

Regardless of how you generated your key pair, with the instructions above you’ll have two files:

  • private.pem contains the private part of the key; use the contents of this file for the property of the component’s metadata.
  • public.pem contains the public part of the key, which you’ll need only if you’re deploying a Worker manually (as per the instructions in the previoius section).

Warning

Protect the private part of your key and treat it as a secret value!