Since the Workers Unbound beta announcement last year, we’ve been hard at work tuning our systems to prepare for the public launch for Workers Unbound. We’ve seen enormous demand from developers, customers, and the Cloudflare community at large. We’ve been inspired to see our users develop a wide range of use cases, from enterprise features to entirely new applications and unlock creativity with personal projects.

Workers Unbound is intended for applications that need long execution times. Today, we are making our extended CPU limits of up to 30 seconds for HTTP requests generally available to customers on the Workers Paid plan. Please note that you will still be able to access Bundled Workers, which are capped at 50 milliseconds, by toggling your Workers at a per script level.

In addition, we are offering a private beta for Cron Triggers of up to 15 minutes for those who need even longer execution times. HTTP Workers are triggered by HTTP requests as part of the Fetch API, whereas Cron Workers are scheduled jobs invoked by Cron Triggers. Our aim with this release is to allow customers to bring all of their intensive workloads to Workers and access the benefits of our edge network, without having to worry about computation limits.

The feedback has been fantastic and we’re excited to see that our work to extend compute limits to unlock new use cases is resonating with our community (please join our Discord server here)!  We want Workers Unbound to be the choice that developers turn to for any workload that might otherwise be run on traditional serverless platforms like AWS Lambda  — and we’re thrilled to see that the message is resonating.

Workers Unbound aims to be the cheapest general purpose computing platform, and we’ve made changes to our pricing plan to solidify that position. As announced during the beta, the Workers Unbound pricing model includes charges for duration and egress as well as requests, but we will not include any additional charges as other providers do, such as API Gateway or CloudFront.

Over the course of development, we also heard your feedback on the cost of egress. We know that these costs are top of mind for developers who need to do intensive storage and transfer operations. In response to that, we have cut our egress in half from \$0.09 per GB to \$0.045 per GB.

Furthermore, we increased the usage that is included in our $5 a month cost, detailed below. Now, as a part of the Workers Paid plan, we will give you more usage for the same rate.

We know that cost can be a major pain point for other serverless providers, and we want to make sure that developers using Workers Unbound can spend more time building applications with cutting edge technologies and less time worrying about their bill. You can read more about our pricing in these docs.

Back in 2017, when we launched the Workers platform, we opted to tackle the lower latency use cases first. This approach helped us serve our existing customers, who wanted to modify Cloudflare products they were already using, like WAF and who usually required little time to execute. We retained the ability to adjust the CPU time limit in special cases. Sometimes we did this for customers with specific needs, and often those customers were our own teams at Cloudflare building on Workers. As these requests became more and more frequent, we began to see the real-world practicality of offering higher compute limits to the general market. Our beta program has helped validate this hypothesis.

We’ve seen some of our early access Unbound testers use the platform for more complex compute use cases like genomic analysis. Dr. Robert Aboukhalil, a software engineer and bioinformatics specialist, used Workers Unbound to build an API that simulates DNA sequencing data, requesting subsets of a reference genome and streaming it back to the user. To power those simulations, he compiled wgsim, an open source genomics tool for simulating sequence reads from a reference genome, from C to WebAssembly using biowasm. Next, he used the human genome referenced hosted on the public repo of the 1,000 Genomes Project as a starting point to apply random modifications to simulate errors introduced during the experiment. You can read more about his explorations in this blog.

In Dr. Aboukhalil’s own words: "Cloudflare Workers Unbound and KV are well-suited for complex workloads such as powering genomics analysis. For example, I was able to build an API that simulates DNA sequencing data. Workers was well suited as it features 0 ms initialization time (i.e. no “cold starts”), runs at the edge (i.e. in a data center close to your users), and has a pricing model that doesn’t require a degree in quantum physics to understand."

We’ve also seen that Workers Unbound can be a critical part of scaling applications at large enterprise companies. Thomson Reuters used Workers Unbound to build EverCache, a cache implementation designed to improve efficiency and load times across thousands of their partner websites.

According to Randy Kleinhuizen, an architect at Thomson Reuters, "We use Cloudflare Workers Unbound and Workers KV to reduce the burden on our origin servers and pre-populate our cache. We are early users of Unbound's long running Workers, and the simple integration with Workers KV has made it easy to use, with consistent performance and reliability."

Furthermore, our testers have taught us that Workers Unbound is a powerful environment for sandboxing and experimentation. Customers who originally used our platform for more simple use cases are able to expand by testing out ideas, prototyping and building out optimizations with Unbound.

As we heard from Kenn North, principal product manager at National Instruments, "Workers has been our go-to tool for scaling and tuning ni.com. We first started using Workers for redirects, and then began using Workers Unbound once we realized it could be a powerful tool for other features such as detecting the location of users and adjusting the experience accordingly. We started experimenting with using includes for deploying common header and footer HTML across the site, and currently we are improving routing, image optimization, and page caching. Our development team loves having the ability to experiment with building new features on top of Workers."

Starting today, Workers Unbound is available to anyone with a Cloudflare Workers Paid subscription. Navigate to the Workers dashboard, click "Change" under the Default Usage Model section, and follow the prompts to enable Unbound on your account. You can also change the Usage Model for individual Workers under the Settings tab of each Worker.

Once enabled, Unbound can also be used through wrangler, the command-line tool for deploying Workers. First, make sure to update wrangler to release 1.15.1 or later. Then, configure the usage model of your Worker by setting the usage_model field in your wrangler.toml to either "bundled" or "unbound".

As a reminder, the “bundled” usage model gives you access to our original Workers model with up to 50ms of compute time. The model “unbound” opts you into the higher execution limits with the pricing listed above. If you don't specify a usage model, new Workers scripts will use the default usage model set through the dashboard.

If you want to try Workers Unbound today, please take a look at this template, licensed under the MIT license, and give it a whirl!

// Try running this script first with Usage Model: Bundled
// see how far it can count.
//
// Then update the script's Usage Model to Unbound to see
// how much further it can go!
//
// note: 1st requests on a connection in Bundled mode
// might get higher cpu allocation than average requests.
 
addEventListener('fetch', event => {
 event.respondWith(handleEvent(event))
})
 
async function handleEvent(event) {
 let { readable, writable } = new TransformStream()
 let countingIsDone = countToOneTrillion(writable)
 event.waitUntil(countingIsDone)
 
 // start streaming response while still counting
 return new Response(readable, {
   status: 200,
   headers: {
     'Content-Type': 'text/plain; charset=utf8',
     'X-Content-Type-Options': 'nosniff',
   },
 })
}
 
async function countToOneTrillion(writableStream) {
 // This is an example of a cpu-heavy long running task.
 //
 // Try your own example here instead!
 // Fractal Generator? ML model training?
 
 const million = 1000000
 const intro = `Hello World!
Let's count to one trillion:
(we'll stop when cpu limits are exceeded)
 
`
 const writer = writableStream.getWriter()
 const encoder = new TextEncoder()
 await writer.write(encoder.encode(intro))
 
 for (let i = 1; i <= million * million; i++) {
   if (i % (2 * million) == 0) {
     // send an update to client every 2M cycles
     const count = i / million
     const line = `${count} million\n`
     await writer.write(encoder.encode(line))
   }
 }
 await writer.close()
 return
}

We hope you give Workers Unbound a try - and if you have any feedback or questions please let us know on our Discord server here! If you are interested in signing up for the beta program for 15 minute Cron Workers, please contact us with this form.

Today the Cloudflare Workers team is thrilled to announce the launch of Cron Triggers. Before now, Workers were triggered purely by incoming HTTP requests but starting today you’ll be able to set a scheduler to run your Worker on a timed interval. This was a highly requested feature that we know a lot of developers will find useful, and we’ve heard your feedback after Serverless Week.

We are excited to offer this feature at no additional cost, and it will be available on both the Workers free tier and the paid tier, now called Workers Bundled. Since it doesn’t matter which city a Cron Trigger routes the Worker through, we are able to maximize Cloudflare’s distributed system and send scheduled jobs to underutilized machinery. Running jobs on these quiet machines is both efficient and cost effective, and we are able to pass those cost savings down to you.

In case you’re not familiar with Unix systems, the cron pattern allows you to schedule jobs to run periodically at fixed intervals or at scheduled times. Cron Triggers in the context of Workers allow users to set time-based invocations for the job. These Workers happen on a recurring schedule, and differ from traditional Workers in that they do not fire on HTTP requests.

Most developers are familiar with the cron pattern and its usefulness across a wide range of applications. Pulling the latest data from APIs or running regular integration tests on a preset schedule are common examples of this.

"We're excited about Cron Triggers. Workers is crucial to our stack, so using this feature for live integration tests will boost the developer experience." - Brian Marks, Software Engineer at Bazaarvoice

Triggers are included at no additional cost! Scheduled Workers count towards your request cap for both the free tier and Workers Bundled, but rest assured that there will be no hidden or extra fees. Our competitors charge extra for cron events, or in some cases offer a very limited free tier. We want to make this feature widely accessible and have decided not to charge on a per-trigger basis. While there are no limits for the number of triggers you can have across an account, note that there is a limit of 3 triggers per Worker script for this feature. You can read more about limits on Workers plans in this documentation.

Cloudflare supports a massive distributed system that spans the globe with 200+ cities. Our nodes are named for the IATA airport code that they are closest to. Most of the time we run Workers close to the request origin for performance reasons (ie SJC if you are in the Bay Area, or CDG if you are lucky enough to be in Paris ???).  In a typical HTTP Worker, we do this because we know that performance is of material importance when someone is waiting for the response.

In the case of Cron Triggers, where the user is running a task on a timed basis, those performance needs are different. A few milliseconds of extra latency do not matter as much when the user isn’t actively waiting for the response. The nature of the feature gives us much more flexibility on where to run the job, since it doesn’t have to necessarily be in a city close to the end user.

Cron Triggers are run on underutilized machines to make the best use of our capacity and route traffic efficiently. For example, a job scheduled from San Francisco at 7pm Pacific Time might be sent to Paris because it’s 4am there and traffic across Europe is low.  Sending traffic to these machines during quiet hours is very efficient, and we are more than happy to pass those cost savings down to you. Aside from this scheduling optimization, Workers that are called by Cron Triggers behave similarly to and have all of the same performance and security benefits as typical HTTP Workers.

At a high level, schedules created through our API create records in our database. These records contain the information necessary to execute the Worker on the given cron schedule. These records are then picked up by another service which continuously evaluates the state of our edge and distributes the schedules among cities. Once the schedules have been distributed to the edge, a service running in the node polls for changes to the schedules and makes sure they get sent to our runtime at the appropriate time.

If you want to know more details about how we implemented this feature, please refer to the technical blog.

With this feature, we’ve expanded what’s possible to build with Workers, and further simplified the developer experience. While Workers previously only ran on web requests, we believe the future of edge computing isn’t strictly tied to HTTP requests and responses.  We want to introduce more types of Workers in the future.

We plan to expand out triggers to include different types, such as data or event-based triggers. Our goal is to give users more flexibility and control over when their Workers run. Cron Triggers are our first step in this direction. In addition, we plan to keep iterating on Cron Triggers to make edge infrastructure selection even more sophisticated and optimized -- for example, we might even consider triggers that allow our users to run in the most energy-efficient data centers.

Cron triggers are live today! You can try it in the Workers dashboard by creating a new Worker and setting up a Cron Trigger.

We launched Cloudflare Workers® in 2017 with the goal of building the development platform that we wished we had. We want to enable developers to build great software while Cloudflare manages the overhead of configuring and maintaining the infrastructure. Workers are with you from the first line of code, to the first application, all the way to a globally scaled product. By making our Edge network programmable and providing servers in 200+ locations around the world, we offer you the power to execute on even the biggest ideas.

Behind the scenes at Cloudflare, we’ve been steadily working towards making development on the Edge even more powerful and flexible. Today, we are excited to announce the next phase of this with the launch of our new platform, Workers Unbound, without restrictive CPU limits in a private beta (sign up for details here).

Workers Unbound is like our classic Cloudflare Workers (now referred to as Workers Bundled), but for applications that need longer execution times. We are extending our CPU limits to allow customers to bring all of their workloads onto Workers, no matter how intensive. It eliminates the choice that developers often have to make, between running fast, simple work on the Edge or running heavy computation in a centralized cloud with unlimited resources.

This platform will unlock a new class of intensive applications with heavy computation burdens like image processing or complex algorithms. In fact, this is a highly requested feature that we’ve previously unlocked for a number of our enterprise customers, and are now in the process of making it widely available to the public.

Workers Unbound is built to be a general purpose computing platform, not just as an alternative to niche edge computing offerings. We want to be more compelling for any workload you'd previously think to run on traditional, centralized serverless platforms — faster, more affordable, and more flexible.

We are excited to offer Workers Unbound to a select group of developers in a private beta. Please reach out via this form with some details about your use case, and we’ll be in touch! We’d love to hear your feedback and can’t wait to see what you build.

Serverless as it’s known today is constrained by being built on top of old paradigms. Most serverless platforms have inherited containers from their cloud computing origins. Cloudflare has had the opportunity to rethink serverless by building on the Edge and making this technology more performant at scale for complex applications.

We reap performance benefits by running code on V8 Isolates, which are designed to start very quickly with minimal cold start times. Isolates are a technology built by the Google Chrome team to power the JavaScript engine in the browser, and they introduce a new model for running multi-tenant code. They provide lightweight contexts that group variables with the code allowed to mutate them.

Isolates are far more lightweight than containers, a central tenet of most other serverless providers’ architecture. Containers effectively run a virtual machine, and there’s a lot of overhead associated with them. That, in turn, makes it very hard to run the workload outside a centralized environment.

Moreover, a single process on Workers can run hundreds or thousands of isolates, making switching between them seamless. That means it is possible to run code from many different customers within a single operating system process. This low runtime overhead is part of the story of how Workers scales to support many tenants.

The other part of the story is code distribution. The ability to serve customers from anywhere in the world is a key difference between an edge-based and a region-based serverless paradigm, but it requires us to ship customer code to every server at once. Isolates come to the rescue again: we embed V8 with the same standard JavaScript APIs you can find in browsers, meaning a serverless edge application is both lightweight and performant. This means we can distribute Worker scripts to every server in every datacenter around the world, so that any server, anywhere, can serve requests bound for any customer.

Performance at scale is top of mind for us because improving performance on our Edge means we can pass those cost savings down to you. We pay the overhead of a JavaScript runtime once, and then are able to run essentially limitless scripts with almost no individual overhead.

Workers Unbound is a truly cost-effective platform when compared to AWS Lambda. With serverless, you should only pay for what you use with no hidden fees. Workers will not charge you for hidden extras like API gateway or DNS request fees.

Serverless Pricing Comparison*

* Based on pricing disclosed on aws.amazon.com/lambda/pricing as of July 24, 2020. AWS’ published duration pricing is based on 1 GB-sec, which has been multiplied by one million on this table for readability. AWS price ranges reflect different regional pricing. All prices rounded to the nearest two decimal places. Data Transfer for AWS is based on Data Transfer OUT From Amazon EC2 to Internet above 1 GB / month, for up to 9.999 TB / month. API Gateway for AWS is based on Rest APIs above 1MM/month, for up to 333MM/month. Both the Workers Unbound and AWS Lambda services provide 1MM free requests per month and 400,000 GB-seconds of compute time per month. DNS Queries rate for AWS is based on the listed price for up to 1 Billion queries / month.

To put our numbers to the test, we deployed a hello world GraphQL server to both Workers and Lambda. The median execution time on Lambda was 1.54ms, whereas the same workload took 0.90ms on Workers. After crunching the numbers and factoring in all the opaque fees that AWS charges (including API Gateway to allow for requests from the Internet), we found that using Workers Unbound can save you up to 75% -- and that’s just for a hello world! Imagine the cost savings when you’re running complex workloads for millions of users.

You might be wondering how we’re able to be so competitive. It all comes down to efficiency. The lightweight nature of Workers allows us to do the same work, but with less platform overhead and resource consumption. The execution times from this GraphQL hello world test are shown below and put platform providers’ overhead on display. Since the test is truly a hello world, the variation is explained by architectural differences between providers (e.g. isolates v. containers).

GraphQL hello world Execution Time (ms) across Serverless Platforms*

* The 128MB memory tier was used for each platform. This testing was run in us-east for AWS, us-central for Google, and us-west for Azure. Each platform test was run at a throughput of 1 request per second over the course of an hour. The execution times were taken from each provider's logging system.

These numbers speak for themselves and highlight the efficiency of the Worker’s architecture. On Workers, you don’t just get faster results, you also benefit from the cost savings we pass onto you.

Workers Unbound is a major change to our platform, so we’ll be rolling it out slowly and tweaking it over time. If you’d like to get early access or want to be notified when it’s ready, sign up for details here!

We’ve got some exciting announcements to share this week. Stay tuned for the rest of Serverless Week!