Your Workers now have access to a low-latency key-value data store which lives inside our network all around the world!

For those who don’t know, Cloudflare Workers is a new type of compute platform, built on top of our global network of 152+ data centers around the world. It allows you to write serverless code which runs in the fabric of the Internet itself, allowing you to engage with your users faster than other platforms can even get a packet to where your code is running. It’s built on a new architecture which eliminates cold starts and dramatically reduces the memory overhead of keeping your code running when compared to a platform like Amazon Lambda.

As powerful as this is, compute is just one component of what you need to build an application, you also need the ability to store data. We evaluated many of the available open source data stores on the market, but ultimately nothing was designed for a world with quite as many distributed nodes as our network. Instead, we have begun releasing our own vision for distributed storage, beginning today.

The Workers KV is a highly distributed, eventually-consistent, key value store. It will allow you to store up to a billion keys and values, and read them with ultra low latency anywhere in the world. It makes it possible to build entire applications with the performance traditionally associated with static content cached by a CDN.

First and foremost, you can build the same types of applications you build today, but in a more fault tolerant and performant way. Reading values from Workers KV is designed to have the same reliability as reading static files, making it much less likely to become unavailable than a traditional database. It’s designed to have the same performance as reading a file cached within our network, close to your users, giving it the speed of serving a static file as well.

That said, we do have some applications which we commonly see as a good entry point into writing code on the network itself. These use-cases combine a serious need for speed with a clean separation from the legacy components of your application which are stuck in a central location (for now!).

Here are just a few of those examples:

An API Gateway sits between your visitors and your API. It commonly handles tasks which would be redundant, time consuming, or slow to implement in each and every service in your system. This includes tasks like rate limiting, access token validation, and routing. They work together to deliver only authenticated requests directly to the appropriate components of your system. It’s also the perfect entry point to developing code which runs everywhere. When you use Cloudflare Workers as an API Gateway, your access tokens get validated at the Cloudflare data center closest to the customer before the request is securely forwarded to your origin.

In this example your authentication system will store a token when a user logs in. I'm using curl, but the backend code for your system is more likely to use whatever interface it has for making HTTPS requests. This request stores a blob of JSON identifying this token in a Worker KV namespace $NAMESPACE_ID with a key of $TOKEN_ID:

curl https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/storage/kv/namespaces/$NAMESPACE_ID/values/$TOKEN_ID \
-X PUT \
-H "X-Auth-Key: $CLOUDFLARE_AUTH_KEY" \
-H "X-Auth-Email: $CLOUDFLARE_AUTH_EMAIL" \
-d '{
  "userId": "bob",
  "expires": "2018-07-11T03:44:12Z"
}'

Your Worker code, which runs on every request, will check if the token the user provides matches one you have stored. A single line of code (TOKEN_STORE.get()) pulls the JSON stored above from the Worker KV

addEventListener('fetch', event => {
 event.respondWith(handleRequest(event.request))
})

async function handleRequest(request) {
 const token = request.headers.get('Authorization')
 if (!token)
   return new Response("An Authorization header is required", {status: 401})

 const tokenInfo = await TOKEN_STORE.get(token, "json")
 if (!tokenInfo)
   return new Response("Invalid token", {status: 403})
 
 if (Date.parse(tokenInfo.expires) < Date.now())
   return new Response(“Token expired”, {status: 403}) 

 request = new Request(request)
 request.headers.set("User-Id", tokenInfo.userId)
 return fetch(request)
}

A secure authentication system which adds virtually no latency at 1/7th the cost of Amazon API Gateway (with so much more flexibility and power)!

Traditionally you’ve had to decide between showing a super fast static site to your visitors, or being able to include dynamic data customizing your site for each visitor. That customization could be showing different products based on the customer’s profile, A/B testing site variants, or even including the customer’s current shopping cart and account information. Rather than waiting for this information to be served from a central database, it’s now possible to store it close to every visitor, delivering a custom page as quickly as you could a static resource.

For example, let’s say we have translations of our site stored as JSON in the KV store. We can dynamically insert this translation data as Javascript into the HTML of our site. In this example our site has a block which looks like this:

<html>
 <head>
   <script>
     var TRANSLATION_DATA = TRANSLATION DATA HERE
   </script>
 </head>

 ...
</html>

Our worker replaces that text with the content of our translations. You could alternatively use a Javascript templating engine or parse the content of the page to do something like Server-Side Includes.

addEventListener('fetch', event => {
  event.respondWith(handleRequest(event.request))
})

async function handleRequest(request) {
  const token = request.headers.get('Authorization')


  const translationsPromise = TRANSLATION_DATA.get(country)
  const response = await fetch(request)
  const translations = await translationsPromise

  let newBody = await response.text()
  const ct = response.headers.get('content-type')
  if (ct.startsWith('text/html') && response.status === 200){
    newBody = newBody.replace('TRANSLATION DATA HERE', translations)
  }

  return new Response(newBody, response)
}

Workers is a full programming environment, meaning this is just the beginning. We have customers rendering their entire React App inside Workers, fully bootstrapping the data required to render their site.

The Workers KV store creates a powerful way to configure your running Workers without having to redeploy them. You might want to implement feature flags to enable or disable features at will, or to dynamically update the data your code uses to make decisions. Workers deploy in under 30 seconds, but it’s common to have more data than can easily fit in Worker code. For example, we have customers interested in using Workers KV to block messages from lost or stolen IoT devices before they ever reach their origin:

addEventListener('fetch', event => {
 event.respondWith(handleRequest(event.request))
})

async function handleRequest(request) {
 const deviceId = request.headers.get('device-id')
 const bannedEntry = await BANNED_DEVICES.get(deviceId)
 if (bannedEntry !== null){
   return new Response("This device has been banned", {status: 403})
 }

 return fetch(request)
}

One thing we’re excited about when we think about the Workers KV store is the potential for building beyond web applications. There are many situations where developers are looking for an easy way to execute code without worrying about provisioning or maintaining infrastructure. One of the most common cases we see is joining systems together.

For example, one of our customers is planning on using Workers KV to connect their Point of Sale system with their Delivery Service’s API:

// The endpoint we have bound this to is polled periodically
addEventListener('fetch', event => {
 event.respondWith(handleRequest(event.request))
})

async function handleRequest(request) {
 const orderResp = await fetch(`https://api.pos-system.com/orders/active`, {
   headers: {
     'Authorization': 'POS_API_KEY'
   }
 })

 const orders = await orderResp.json()

 for (var i=0; i < orders.length; i++){
   let order = orders[i]

   const syncedData = await SYNCED_ORDERS.get(order.id, "json")

   // If the order data is newer than the last data we sent to the delivery company,
   // update it.
   if (syncedData.modifiedAt < order.modifiedAt) {
     await fetch(`https://api.delivery-system.com/orders/${ order.id }`, {
       method: 'POST',
       body: JSON.stringify(order),
       headers: {
         'Content-Type': 'application/json',
         'Authorization': 'DELIVERY_API_KEY'
       }
     })

     await SYNCED_ORDERS.put(order.id, JSON.stringify(order))
   }
 }

 return new Response("?")
}

Workers KV is launching today in a limited beta. As we get feedback and operational experience we will be relaxing our storage limits and granting access to more users. While we may have more restrictive limits during beta, you can design your applications around the following characteristics:

• Up to 1 billion keys per namespace

• Keys of up to 2 kB

• Values of up to 64 kB

• Eventually consistent, global consistency within 10 seconds

• 100k+ reads per second per key

• Up to one write per second per key

We worked hard to make the pricing of Workers KV easy to understand and affordable for virtually any use case. Your $5 monthly Workers compute minimum includes 1 GB of KV storage and up to 10 million KV reads. If you use less than the 10 million included Worker requests now, you can use KV without paying a single cent more.

Beyond the minimums, Workers KV is billed at $0.50 per GB-month of additional storage and $0.50 per million additional KV reads.

To get beta access sign up here, we can’t wait to see what you build!

Subscribe to the blog for daily updates on all of our announcements.

We’re very excited to announce that Cloudflare Workers are now integrated into the Serverless framework as a serverless cloud provider! Serverless’ open source framework has become a must-have for many developers, and we want to make it as simple as possible to harness the power of Cloudflare’s distributed computing network.

Workers have become essential to the way people build applications on the web. The expressiveness of modern JavaScript combined with sub-30 second deploys to Cloudflare’s network of 152+ datacenters means that you can truly build your application into our global compute network. Up until this point, deploying Workers required doing all of your editing through our browser-based IDE or developing one’s own custom tooling on top of our API. But many developers have their own environments and are already familiar with the Serverless framework, so it seemed natural that we build first-class support for Workers into Serverless!

You can now define the entire structure and routing behavior of your Workers scripts in code and deploy them with ease using serverless deploy from your own development environment. Store configuration files in version control alongside your application code. And feel more confident testing your application with serverless invoke, a new way to quickly send requests to endpoints of interest with specific arguments and headers.

Serverless is a paradigm for building applications without concern for the underlying infrastructure. It lets developers focus on writing code and lets them deploy quickly and cheaply to a cloud provider which manages servers, networking, and configuration.

The Serverless framework takes this a step further. It empowers developers to write applications with consistent tooling and project structure, which speeds up development and simplifies deployment to common cloud providers.

Our new plugin lets you use serverless command line tool, which you may already be accustomed to, but with Cloudflare Workers! Define the structure of your Worker in serverless.yml and serverless deploy it to our 152+ data centers around the world.

How simple is it? Here’s a complete serverless.yml for a Slackbot running on Workers. Serverless uses the idea of functions (as in functions-as-service) to separate concerns within an application. For Workers, a function is your application, and the script field refers to the name of your Worker script locally on disk.

service:
    name: slack-bot
    config:
      accountId: CLOUDFLARE_ACCOUNT_ID 
      zoneId: CLOUDFLARE_ZONE_ID 
      workers:
        slackbot:
          routes:
            - slackbot.example.com

provider:
  name: cloudflare

plugins:
  - serverless-cloudflare-workers

functions:
  SlackBot:
    worker: slackbot
    script: bot

Learn how retrieve your Cloudflare account and zone IDs

To deploy your new Worker, simply run serverless deploy or serverless deploy -f SlackBot.

$ npm install -g serverless
$ serverless create --template cloudflare-workers --path new-project
$ cd new-project
$ npm install
$ export CLOUDFLARE_AUTH_EMAIL=you@example.com
$ export CLOUDFLARE_AUTH_KEY=YOUR_API_KEY
$ serverless deploy

Use the cloudflare-workers-enterprise template if you're on an enterprise plan in order to deploy multiple scripts to Workers.

Interested? Get started by reading the docs.

Looking to build even more powerful Workers? Check out the recipes on the docs about including NPM modules in your project and performing additional routing within your functions.

Are you building something cool with Workers? Let us know!

If you are in the San Francisco Bay Area, and are interested in hearing from Bay Area serverless experts and explorers, you're invited to come by tonight's Serverless Meetup. RSVP here! Doors open at 6.

Recently, Google officially launched Android 9 Pie, which includes a slew of new features around digital well-being, security, and privacy. If you’ve poked around the network settings on your phone while on the beta or after updating, you may have noticed a new Private DNS Mode now supported by Android.

This new feature simplifies the process of configuring a custom secure DNS resolver on Android, meaning parties between your device and the websites you visit won’t be able to snoop on your DNS queries because they’ll be encrypted. The protocol behind this, TLS, is also responsible for the green lock icon you see in your address bar when visiting websites over HTTPS. The same technology is useful for encrypting DNS queries, ensuring they cannot be tampered with and are unintelligible to ISPs, mobile carriers, and any others in the network path between you and your DNS resolver. These new security protocols are called DNS over HTTPS, and DNS over TLS.

Android Pie only supports DNS over TLS. To enable this on your device:

1. Go to Settings → Network & internet → Advanced → Private DNS.

2. Select the Private DNS provider hostname option.

3. Enter 1dot1dot1dot1.cloudflare-dns.com and hit Save.

4. Visit 1.1.1.1/help (or 1.0.0.1/help) to verify that “Using DNS over TLS (DoT)” shows as “Yes”.

And you’re done!

So how do DNS over HTTPS and DNS over TLS fit into the current state of internet privacy?

TLS is the protocol that encrypts your traffic over an untrusted communication channel, like when browsing your email on a cafe’s wireless network. Even with TLS, there is still no way of knowing if your connection to the DNS server has been hijacked or is being snooped on by a third party. This is significant because a bad actor could configure an open WiFi hotspot in a public place that responds to DNS queries with falsified records in order to hijack connections to common email providers and online banks. DNSSEC solves the problem of guaranteeing authenticity by signing responses, making tampering detectable, but leaves the body of the message readable by anyone else on the wire.

DNS over HTTPS / TLS solves this. These new protocols ensure that communication between your device and the resolver is encrypted, just like we’ve come to expect of HTTPS traffic.

However, there is one final insecure step in this chain of events: the revealing of the SNI (server name indication) during the initial TLS negotiation between your device and a specific hostname on a server. The requested hostname is not encrypted, so third parties still have the ability to see the websites you visit. It makes sense that the final step in completely securing your browsing activity involves encrypting SNI, which is an in-progress standard that Cloudflare has joined other organizations to define and promote.

You may have noticed that the private DNS field does not accept an IP address like 1.1.1.1 and instead wants a hostname like 1dot1dot1dot1.cloudflare-dns.com. This doesn’t exactly roll off the tongue, so we’re working on deploying an easier to remember address for the resolver, and will continue to support 1.1.1.1, 1.0.0.1, and 1dot1dot1dot1.cloudflare-dns.com.

Google requires a hostname for this field because of how mobile carriers are adapting to a dual-stack world in which IPv4 and IPv6 coexist. Companies are adopting IPv6 much more rapidly than generally expected, and all major mobile carriers in the US support it, including T-Mobile who has gone completely IPv6. In a world where the approximately 26 billion internet-connected devices vastly outnumber the 4.3 billion IPv4 addresses, this is good news. And in a forward-thinking move, Apple requires that all new iOS apps must support single-stack IPv6 networks.

However, we still live in a world with IPv4 addresses, so phone manufacturers and carriers have to architect their systems with backwards compatibility in mind. Currently, iOS and Android request both A and AAAA DNS records, which contain the IP address(es) corresponding to a domain in version 4 and version 6 format, respectively. Try it out yourself:

$ dig A +short 1dot1dot1dot1.cloudflare-dns.com
1.0.0.1
1.1.1.1

$ dig AAAA +short 1dot1dot1dot1.cloudflare-dns.com
2606:4700:4700::1001
2606:4700:4700::1111

To talk to a device with only an IPv4 address over an IPv6 only network, the DNS resolver has to translate IPv4 addresses into the IPv6 address using DNS64. The requests to those translated IP addresses then go through the NAT64 translation service provided by the network operator. This is all completely transparent to the device and web server.

Learn more about this process from APNIC.

A few months ago, we announced the world’s fastest, privacy-first, recursive DNS resolver, 1.1.1.1. It’s been exciting watching the community reaction to this project, and to be in a position where we can promote new standards around private DNS.

The Cloudflare network helps to make measurable improvements to the Internet by rolling out security updates to millions of websites at once. This allows us to provide free SSL certificates to any website, and to implement state-of-the-art security for our customers.

We saw the same potential impact when deciding to build 1.1.1.1. From launch, we wanted people to be able to connect to their favorite websites faster, and to ensure that no entity between their computer and the origin web server was recording their browsing history. We’re proud to have achieved that goal with the fastest public DNS resolver in the world.

Consumer adoption of the resolver has been strong, and it makes sense: new legislation allows ISPs to track and sell your web history. But not everyone feels comfortable changing the default DNS resolver on their computer or home network. We want to empower IT departments and network administrators to change the default DNS resolver for their organization, at the network or device level. Our fast, privacy-centric 1.1.1.1 project can secure your users on the Internet, and you’ll always know that they’ll be the first to benefit from the work of Internet standards bodies like the IETF.

If you, or your IT department, are interested, please get in touch! We’d be delighted to answer your questions and we'll try to send you some "trendy" 1.1.1.1 stickers.