This is an investment fund started in partnership with Venrock, Pelion Venture Partners, and New Enterprise Associates. We created the fund to provide developers with resources so that they can build apps using the Cloudflare network and our serverless product, Workers, which enables developers to create applications without configuring or maintaining infrastructure. The goal is to fuel a new economy that grows into a thriving ecosystem so that developers’ serverless innovations can enjoy commercial success.  

Cloudflare Apps with Workers allows developers to package Workers, delivering new worker-powered experiences to Cloudflare customers, all within a few clicks via Cloudflare Apps.

Our CTO, John Graham-Cumming talks about it in a recently recorded video:

In short, Cloudflare is looking for apps that will advance our mission to help build a better Internet: one that is safe, fast and reliable.   We are seeking out apps that have a clear vision, delight customers by the ease of use and align with our vision. Having already seen multiple use cases around custom application security, data loss prevention, and bot mitigation, we can’t wait to see what else you come up with.

We welcome apps coming from a variety of sources, ranging from standalone developers who have identified a particular market opportunity, to engineers who realize their internal idea has utility for a wider audience.  Since our beta launch of Cloudflare Apps with Workers we’ve already seen keen interest across developers who are looking to bundle and deliver complex worker logic for anyone else to consume by publishing to the Apps marketplace.  

With our fund we are helping this move faster.

Today we are announcing a public beta for our Cloudflare Apps with Workers!  If you are a developer who has been using Workers or Cloudflare Apps, this is a significant step forward to bring together our server-less platform allowing you the next wave of innovation in the Cloudflare marketplace.

Wait!  Yet more Workers news?  It’s already been a furious year of releases for Workers, from our GA launch in February to numerous improvements including the beta of Cache API and a flurry of updates during Cloudflare’s Birthday week, where we made available our K/V Storage and WASM support.  With this beta, developers can now package all Workers capabilities, deliver new worker-powered experiences to Cloudflare customers all within a few clicks via Cloudflare Apps.

Now your Apps can be more powerful, and Workers code running on the Cloudflare network are the engine that can take you there.   If you’ve successfully built and deployed a worker on your own domain, you can package it as an App and bring your idea to the Cloudflare Marketplace.  

Apps and Workers Life of a Request

New App experiences are possible including but not limited to personalization, experimentation with A/B testing, custom security, content validation, and localization.

To package a Worker in your App as an additional resource in your install.json, simply add a reference to your Worker script similar to how DNS entries were declared before.

{
	"resources": [...],
	"hooks": [...],
	"workers": [{
		"src": "./worker.js"
	}]
}

You can also deliver custom variables as install options which can then be referenced in Workers; useful for apps who may need to include a service specific token at App install time.

// inside src/worker.js
addEventListener('fetch', event => {
  event.respondWith(workerFn(event.request))
  let someOptionFromInstall = INSTALL_OPTIONS.UserAgents // UserAgents was selected by siteowner in previewer
})

As before, when you submit your app for approval and review, the submission process will gather your app  and worker  sources and make it available for our Moderation Team to review.  Once successfully through the Moderation process, you can expect an additional Security Review of your Worker, before this app will be made available just like any App is today.

Back in August, we announced the upcoming App with Worker capability and since then we’ve seen great interest across our developers and partners who are eager to put their Workers based solutions into the hands to a much broader audience We are continuing to welcome new App Developers in our beta. Apply below to be part of our beta program.

Sign-up to Join the beta!

• Cloudflare Apps with Workers

• Cloudflare Workers Service Providers

Why now? Over the course of the past few months we've seen accelerating interest in Workers, and we frequently field the question on what we are doing to combine our growing ecosystem around Workers, and our unique deliverability capability, Cloudflare Apps. To meet this need, we have introduced two programs, Apps with Workers and Workers Service Providers. Let’s dig into the details:

First, we are announcing the upcoming availability of Cloudflare Apps, powered by embeddable Workers. This will allow any developer to build, deploy and in the near future package Workers to distribute to third parties, all using the Cloudflare Apps platform. It will be, in effect, the world's first serverless Apps platform.

Today, it's easy to develop Workers using our UI or API. The ability to App-ify Workers opens up a whole new promise to those who prefer to deal in clicks and not code. For our Apps developers, Apps with Workers allows for more complex Apps offerings running on Cloudflare, and for our customers the next generation in Apps. So, while we are actively putting the finishing touches on this capability we are opening up this pilot program for select developers. We have a limited early access to program. To apply, click here for more details.

Second, we are announcing the upcoming availability of Cloudflare Worker Service providers. While many Cloudflare customers write Cloudflare Workers for themselves, many customers want to focus on their core business and bring in the development expertise when they need it. The goal is simple: make it easy for our customers to connect to an ecosystem of developers and Apps, and to grow a vibrant marketplace around customers and partners. Moving forward, in addition to Apps, we will support the ability to post Solutions and Services backed by a curated set of consultants, experts and System Integrators, all adding a new richness to the Cloudflare ecosystem. We are excited to hear from our community so drop us a line.

Images courtesty of DroneDeploy

When we launched Workers a few months ago, much of the focus was on use cases surrounding websites running on origins that needed extra oomph. With Workers you can easily take a site, introduce a raft of personalization capabilities, A/B test changes or even aggregate a set of API responses around a range of services. In short by layering in Cloudflare Workers we can take origin websites and do transformational things.

One of the joys of a platform, is that you never know where you are going to see the next use case. Enter DroneDeploy

DroneDeploy is a cloud platform that makes it easy to collect and analyze drone imagery and data. Simply install DroneDeploy on your mobile device and connect to a DJI drone. DroneDeploy flies the drone, collects the imagery, then stitches the photos into maps.

The maps can show things like crop conditions & stress, construction project progress, or even thermal temperature ranges across vast solar farms or for search and rescue situations.

Using plant health algorithms applied to drone-generated maps, growers can pinpoint crop stress in their fields and stomp out pests, disease, or irrigation issues.

With Thermal Live Map, it’s possible to inspect solar farms from the sky in minutes to detect broken photocells in solar panels that are in need of repair.

You can then upload the images to the cloud and make high res maps and 3D models. With these you can perform deeper analysis (such as volumes, distances, plant health, etc), share and collaborate with coworkers, or move the maps and models into applications like CAD or Agriculture Management Platforms.

Check out how we were able to draw a flight path over Cloudflare’s HQ. The drone flew around the building and captured imagery that we turned into a map and 3D model.

It’s important to understand that they want to maintain architectural freedom around the many services they use to make their service. As with many software stacks today, they use GCP, AWS, and others, but they want to maintain flexibility in their network routing and authentication layer.

By offering a dramatically better experience to drone users in the field, they can both push the authentication out in front of a CDN and also serve collected images directly from our CDN (typically hundreds or thousands of tiles used to render maps or 3D models). Many of DroneDeploy’s users operate in highly variable network conditions on job sites or in the field. Workers allows them to push their authentication to the edge; and use Workers to build a custom signed URL to ensure the correct images are surfaced to the correct consumer - in effect ensuring their multi-tenancy image storage model is safe guarded at the edge. To do this, DroneDeploy employs a URL authentication method commonly known as request signing which uses the Web Crypto API.

Commenting on this Eric Hauser, VP Engineering of DroneDeploy detailed the upside of Cloudflare Workers for his team:

Cloudflare Workers provided us with flexibility when we ran into limitations with the shared capabilities of our primary infrastructure providers CDNs. Unique enterprise requirements around authentication, data security, and locality require us to have flexibility at our routing layer. From just the work we’ve done around authentication to date, we see an exciting and productive relationship with Cloudflare.

Let's peel back the layers and understand how they use Workers.

DroneDeploy uses standard JWT authentication - if you are not sure what a JWT Token is, read more here. So the general flow requires the Worker to:

1. Intercept requests for images from the DroneDeploy mobile app or website. These requests can number in the hundreds or thousands of image tiles all of which are needed to render a typical map or 3D model and are stored on either S3 or Google Cloud Storage.

2. Ensure the correct JSON Web Token (JWT) is present.

3. Assuming the token is valid, HMAC sign the URL, set cache headers, and return the appropriate file.

Let's look at each step - note we filtered out some components of the code for security reasons.

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

/**
 * Intercept a request
 * Validate the provided JWT credentials
 * If valid: 
 *   rewrite the request to the storage backend 
 *   sign the request with our backend credentials
 *   return the response from the storage backend
 * If not valid:
 *   return a 403 Forbidden response
 */
function handleFetch(request) {
  if (!(await isValidJwt(request))) {
    return new Response('Invalid JWT', { status: 403 })
  }
  const gsBaseUrl = createGoogleStorageUrl(request);
  const gsHeaders = new Headers();
  gsHeaders.set('Date', new Date().toUTCString());  // Required by Google for HMAC signed URLs
  const signature =  await hmacSignature(gsBaseUrl, gsHeaders);
  gsHeaders.set('Authorization', 'AWS ' + HMAC_KEY + ':' + signature);
  return fetch(new Request(gsBaseUrl, {headers: gsHeaders}))
}

Now check for the JWT Token

/**
 * Parse the JWT and validate it.
 *
 * We are just checking that the signature is valid, but you can do more that. 
 * For example, check that the payload has the expected entries or if the signature is expired..
 */ 
async function isValidJwt(request) {
  const encodedToken = getJwt(request);
  if (encodedToken === null) {
    return false
  }
  const token = decodeJwt(encodedToken);
  return isValidJwtSignature(token)
}

/**
 * For this example, the JWT is passed in as part of the Authorization header,
 * after the Bearer scheme.
 * Parse the JWT out of the header and return it.
 */
function getJwt(request) {
  const authHeader = request.headers.get('Authorization');
  if (!authHeader || authHeader.substring(0, 6) !== 'Bearer') {
    return null
  }
  return authHeader.substring(6).trim()
}

Now decode the JWT Token

/**
 * Parse and decode a JWT.
 * A JWT is three, base64 encoded, strings concatenated with ‘.’:
 *   a header, a payload, and the signature.
 * The signature is “URL safe”, in that ‘/+’ characters have been replaced by ‘_-’
 * 
 * Steps:
 * 1. Split the token at the ‘.’ character
 * 2. Base64 decode the individual parts
 * 3. Retain the raw Bas64 encoded strings to verify the signature
 */
function decodeJwt(token) {
  const parts = token.split('.');
  const header = JSON.parse(atob(parts[0]));
  const payload = JSON.parse(atob(parts[1]));
  const signature = atob(parts[2].replace(/_/g, '/').replace(/-/g, '+'));
  return {
    header: header,
    payload: payload,
    signature: signature,
    raw: { header: parts[0], payload: parts[1], signature: parts[2] }
  }
}

/**
 * Validate the JWT.
 *
 * Steps:
 * Reconstruct the signed message from the Base64 encoded strings.
 * Load the RSA public key into the crypto library.
 * Verify the signature with the message and the key.
 */
async function isValidJwtSignature(token) {
  const encoder = new TextEncoder();
  const data = encoder.encode([token.raw.header, token.raw.payload].join('.'));
  const signature = new Uint8Array(Array.from(token.signature).map(c => c.charCodeAt(0)));
  const jwk = {
    alg: 'RS256',
    e: 'AQAB',
    ext: true,
    key_ops: ['verify'],
    kty: 'RSA',
    n: RSA_PUBLIC_KEY
  };
  const key = await crypto.subtle.importKey('jwk', jwk, { name: 'RSASSA-PKCS1-v1_5', hash: 'SHA-256' }, false, ['verify']);
  return crypto.subtle.verify('RSASSA-PKCS1-v1_5', key, signature, data)
}

Now HMAC sign the URL, and return the file.

/**
 * Rewrite the URL from the original request to Google Storage API and bucket.
 */
function createGoogleStorageUrl(request) {
  const googlePrefix = 'https://storage.googleapis.com/BUCKET_NAME';
  const path = new URL(request.url).pathname;
  return new URL(googlePrefix + path)
}

/**
 * Create the HMAC signature for the Google Storage URL.
 */
async function hmacSignature(url, headers) {
  const encoder = new TextEncoder()
  const message = createMessage(url, headers)
  const key = await crypto.subtle.importKey('raw', encoder.encode(HMAC_SECRET), {name: 'HMAC', hash: 'SHA-1'}, false, ['sign'])
  const mac = await crypto.subtle.sign('HMAC', key, encoder.encode(message))
  return btoa(String.fromCharCode(...new Uint8Array(mac)))
}

/**
 * Google requires a specific format for the message that is signed.
 * More documentation can be found here:
 * https://cloud.google.com/storage/docs/migrating
 */
function createMessage(url, headers) {
  const verb = 'GET'
  return [
    verb,
    ‘’,  // GET requests don’t have Content-MD5 or Content-Type headers, so use empty strings
    ‘’,
    headers.get(‘Date’),
    url.pathname
  ].join('\n')
}

So the upside is clear - Authentication at the Edge provides flexibility, and scale but also means that DroneDeploy is not locked into an architecture that would prevent their ability to choose the best-in-class capabilities they need from GCP, AWS and more.

This Worker is the first of a few DroneDeploy are exploring. In next generation Workers, DroneDeploy is looking to deliver a range of improvements all with a view of optimizing their customers experience by using Cloudflare’s cache in addition to other features Cloudflare has to offer. We’ll update the blog at that time.

If you have a worker you'd like to share, or want to check out workers from other Cloudflare users, visit the “Recipe Exchange” in the Workers section of the Cloudflare Community Forum.