The Serverless Framework helps you develop and deploy serverless applications using Cloudflare Workers. It’s a CLI that offers structure, automation, and best practices out-of-the-box, allowing you to focus on building sophisticated, event-driven, serverless architectures, comprised of Functions and Events.
The Serverless Framework manages your code as well as your infrastructure. It lets you manage your Worker routing in a flat configuration file that you can keep in alongside the rest of your code in version control. And it intelligently manages your routes as you edit them and re-deploy your application.
Learn more about using Cloudflare Workers with Serverless.
A Function is a Cloudflare Worker. It’s an independent unit of deployment, like a microservice. It’s merely code, deployed on Cloudflare’s 152+ PoPs (points of presence), that is most often written to perform a single job, such as:
Anything that triggers a Cloudflare Worker Event to execute is regarded by the Framework as an Event. The only event that triggers a Cloudflare Worker is an HTTP request. Since the only event that can trigger a Worker is an HTTP request, declaring events is optional, and only used to declare specific endpoints that can be called by
serverless invoke. This is useful for defining specific hooks into your application for testing.
A Service is the Serverless Framework’s unit of organization. You can think of it as a project file, though you can have multiple services for a single application. It’s where you define your Functions and the routes they will live on, all in one file entitled
serverless.yml. Non-Enterprise Cloudflare accounts can only deploy one Function (that can be deployed to multiple routes), while Enterprise Cloudflare accounts can deploy multiple Functions at once:
# serverless.yml service: name: hello-world config: accountId: CLOUDFLARE_ACCOUNT_ID zoneId: CLOUDFLARE_ZONE_ID workers: hello: routes: - example.com/hello/* foo_script: routes: - example.com/foo/* provider: name: cloudflare plugins: - serverless-cloudflare-workers functions: helloWorld: # What the script will be called on Cloudflare worker: hello # The name of the script on your machine, omitting the .js file extension script: helloWorld # Events are only relevant to the `serverless invoke` command and don’t affect deployment in any way events: - http: url: example.com/hello/user method: GET headers: someKey: someValue # Only Enterprise accounts would be allowed to add this second function and its corresponding route above foo: worker: foo_script script: bar events: - http: url: example.com/foo/bar method: GET
You will also need to set your Global API key from Cloudflare as an environmental variable named
CLOUDFLARE_AUTH_KEY, and your Cloudflare account email as an environmental variable named
CLOUDFLARE_AUTH_EMAIL. You can get your Global API key from your Cloudflare profile page.
Environmental variables are variables that live inside your terminal.
For Mac and Linux users, you can set environmental variables like this:
export CLOUDFLARE_AUTH_KEY=YOUR_API_KEY_HERE export CLOUDFLARE_AUTH_EMAIL=YOUR_CLOUDFLARE_EMAIL
And for Windows (CMD) users, you can set environmental variables like this:
set CLOUDFLARE_AUTH_KEY=YOUR_API_KEY_HERE set CLOUDFLARE_AUTH_EMAIL=YOUR_CLOUDFLARE_EMAIL
You’ll need to redefine your environmental variables after each time you close your terminal.
If you’re not an enterprise customer and you want to execute different code on multiple routes with only one funciton, we recommend writing code based off of our conditional routing template to check your route and execute different code accordingly. You can also write workers in separate files and compile it into one worker with webpack.
When you deploy with the Framework by running
serverless deploy, everything in
serverless.yml is deployed at once.