As part of this announcement, we are listing BYOIP on the relevant product pages, developer documentation, and UI support for controlling your prefixes. Previous support was API only.

Customers choose BYOIP with Cloudflare for a number of reasons. It may be the case that your IP prefix is already allow-listed in many important places, and updating firewall rules to also allow Cloudflare address space may represent a large administrative hurdle. Additionally, you may have hundreds of thousands, or even millions, of end users pointed directly to your IPs via DNS, and it would be hugely time consuming to get them all to update their records to point to Cloudflare IPs.

Over the last several quarters we have been building tooling and processes to support customers bringing their own IPs at scale. At the time of writing this post we’ve successfully onboarded hundreds of customer IP prefixes. Of these, 84% have been for Magic Transit deployments, 14% for Layer 7 deployments, and 2% for Spectrum deployments.

When you BYOIP with Cloudflare, this means we announce your IP space in over 200 cities around the world and tie your IP prefix to the service (or services!) of your choosing. Your IP space will be protected and accelerated as if they were Cloudflare’s own IPs. We can support regional deployments for BYOIP prefixes as well if you have technical and/or legal requirements limiting where your prefixes can be announced, such as data sovereignty.

You can turn on advertisement of your IPs from the Cloudflare edge with a click of a button and be live across the world in a matter of minutes.

All BYOIP customers receive network analytics on their prefixes. Additionally all IPs in BYOIP prefixes can be considered static IPs. There are also benefits specific to the service you use with your IP prefix on Cloudflare.

Cloudflare has a robust Layer 7 product portfolio, including products like Bot Management, Rate Limiting, Web Application Firewall, and Content Delivery, to name just a few. You can choose to BYOIP with our Layer 7 products and receive all of their benefits on your IP addresses.

For Layer 7 services, we can support a variety of IP to domain mapping requests including sharing IPs between domains or putting domains on dedicated IPs, which can help meet requirements for things such as non-SNI support.

If you are also an SSL for SaaS customer, using BYOIP, you have increased flexibility to change IP address responses for [custom_hostnames](https://developers.cloudflare.com/ssl/ssl-for-saas/status-codes/custom-hostnames/) in the event an IP is unserviceable for some reason.

Spectrum is Cloudflare’s solution to protect and accelerate applications that run any UDP or TCP protocol. The Spectrum API supports BYOIP today. Spectrum customers who use BYOIP can specify, through Spectrum’s API, which IPs they would like associated with a Spectrum application.

Magic Transit is a Layer 3 security service which processes all your network traffic by announcing your IP addresses and attracting that traffic to the Cloudflare edge for processing.  Magic Transit supports sophisticated packet filtering and firewall configurations. BYOIP is a requirement for using the Magic Transit service. As Magic Transit is an IP level service, Cloudflare must be able to announce your IPs in order to provide this service

Before Cloudflare can announce your prefix we require some documentation to get started. The first is something called a ‘Letter of Authorization’ (LOA), which details information about your prefix and how you want Cloudflare to announce it. We then share this document with our Tier 1 transit providers in advance of provisioning your prefix. This step is done to ensure that Tier 1s are aware we have authorization to announce your prefixes.

Secondly, we require that your Internet Routing Registry (IRR) records are up to date and reflect the data in the LOA. This typically means ensuring the entry in your regional registry is updated (i.e. ARIN, RIPE, APNIC).

Once the administrivia is out of the way, work with your account team to learn when your prefixes will be ready to announce.

We also encourage customers to use RPKI and can support this for customer prefixes. We have blogged and built extensive tooling to make adoption of this protocol easier. If you’re interested in BYOIP with RPKI support just let your account team know!

Each customer prefix can be announced via the ‘dynamic advertisement’ toggle in either the UI or API, which will cause the Cloudflare edge to either announce or withdraw a prefix on your behalf. This can be done as soon as your account team lets you know your prefixes are ready to go.

Once the IPs are ready to be announced, you may want to set up ‘delegations’ for your prefixes. Delegations manage how the prefix can be used across multiple Cloudflare accounts and have slightly different implications depending on which service your prefix is bound to. A prefix is owned by a single account, but a delegation can extend some of the prefix functionality to other accounts. This is also captured on our developer docs. Today, delegations can affect Layer 7 and Spectrum BYOIP prefixes.

Layer 7: If you use BYOIP + Layer 7 and also use the SSL for SaaS service, a delegation to another account will allow that account to also use that prefix to validate custom hostnames in addition to the original account which owns the prefix. This means that multiple accounts can use the same IP prefix to serve up custom hostname traffic. Additionally, all of your IPs can serve traffic for custom hostnames, which means you can easily change IP addresses for these hostnames if an IP is blocked for any reason.

Spectrum: If you used BYOIP + Spectrum, via the Spectrum API, you can specify which IP in your prefix you want to create a Spectrum app with. If you create a delegation for prefix to another account, that second account will also be able to specify an IP from that prefix to create an app.

If you are interested in learning more about BYOIP across either Magic Transit, CDN, or Spectrum, please reach out to your account team if you’re an existing customer or contact sales@cloudflare.com if you’re a new prospect.

In today’s post we’re going to talk about building a CI/CD pipeline for Cloudflare Worker’s using Travis CI. If you aren’t yet aware, Cloudflare Workers allow you to run Javascript in all 165 of our data centers, and they deploy globally in about 30 seconds. Learn more here.

There are a few steps before we get started. We need to have a Worker script we want to deploy, some optional unit tests for the script, a serverless.yml  file to deploy via the Serverless Framework, a .gitignore file to ignore the node_modules folder, and finally, a .travis.yml configuration file. All of these files will live in the same GitHub repository, which should have a final layout like:

----- worker.js
----- serverless.yml
----- test
      . worker-test.js
----- node_modules
----- package.json
----- package-lock.json
----- .travis.yml
----- .gitignore

In a recent post we discussed a method for testing Workers. We’ll reuse this method here to test a really simple Worker script below which simply returns Hello World! in the body of the response. We will name our Worker worker.js.

addEventListener('fetch', event => {
  event.respondWith(handleRequest(event.request))
})
async function handleRequest(request) {
  return new Response('Hello World!')
}

We will create a single test case following the method discussed unit testing blog post.

before(async function () {
   Object.assign(global, new (require('@dollarshaveclub/cloudworker'))(require('fs').readFileSync('worker.js', ‘utf8’)).context)
})
// replace worker.js here with the name of your worker file
const assert = require('assert')

describe('Worker Test', function() {
    it('Response with a body that says hello', async function () {
    var url = new URL('https://travis.example.com')
    var req = new Request(url)
    var res = await handleRequest(req)
    var body = await res.text()
    assert.equal(body, 'Hello World!')
    })
})

Then we’ll update our package.json file to include:

"scripts": {
  "test": "mocha"
}

And install mocha with npm install mocha --save-dev and cloudworker with npm install @dollarshaveclub/cloudworker --save-dev.

Next, we’ll need a serverless.yml file to deploy the worker. This is a config file which is used by the Serverless Framework to deploy serverless apps to supported providers. We became a provider some time ago, and we will use the framework to deploy our Workers in this example.

We will run the sls deploy command in our Travis config and it will pick up our serverless.yml to deploy the Worker for us. serverless.yml will reference ENV variables which we will pass to Travis in the final section of the post.

NOTE: You can deploy with any arbitrary script. We’re using the Serverless Framework in this example because we already integrate with them and getting started is straightforward.

Our serverless.yml will look like:

service:
  name: travis-example
  
provider:
  name: cloudflare
  
config:
  accountId: ${env:CLOUDFLARE_ACCOUNT_ID}
  zoneId: ${env:CLOUDFLARE_ZONE_ID}
  
plugins:
  - serverless-cloudflare-workers
  
functions:
  deploy-from-travis:
    name: travis-deployed-worker
    script: worker

Make sure to install both the Serverless Framework, and the Cloudflare Workers plugin with npm install --save serverless and npm install --save serverless-cloudflare-workers.

Below you’ll see the final .travis.yml and we’ll walk through each piece of it.

language: node_js
node_js:
  - "node"
  
deploy:
  - provider: script
  script: sls deploy
  skip_cleanup: true
  on:
    branch: main

Before diving in, Travis has some great resources on deploying node.js projects here. While this isn’t strictly what we’re doing, it’s a great jumping off point.

So what does this .travis.yml mean? First, we’re telling Travis CI to use the most recent node.js image (you have the option to specify). Then we specify the command to run to actually do the deployment, sls deploy, but only when the main branch is involved in the build. Travis will run npm test for us as it’s default for any node.js project, which will execute our unit tests.

The skip_cleanup: true prevents any conflicts with git during the test and deploy process.

Finally! We’re almost there. Setting up Travis CI is really simple. Once you’ve got your account created, make sure your authorize Travis to access the repo which contains the worker, your tests, .travis.yml, and your .serverless.yml.

Next up is adding environmental variables to the build. In this case it’s going to be our CLOUDFLARE_AUTH_EMAIL and CLOUDFLARE_AUTH_KEY values which Serverless picks up to auth API requests.

I also add CLOUDFLARE_ACCOUNT_ID and CLOUDFLARE_ZONE_ID as we referenced them in serverless.yml. Finally I set SLS_DEBUG=*, just to catch any issues from Serverless.

You can add these ENV variables in a variety of ways outlined here. In this example we’re going to add them directly in the Travis UI so they don’t show up anywhere in the repo (as some of them are sensitive).

Navigate to the repo in the Travis UI, and hit the ‘more options’ dropdown to add ENV variables.

Now PRs will trigger a test build, and a merge to main a test build and a deployment! Go ahead and test it out.

And that’s it! Did you find this useful? Please let us know if we can make this tutorial better. Thanks.

More specifically, if your Worker includes a number of functions, it’s important to ensure each function does what it’s intended to do in addition to ensuring the output of the entire Worker returns as expected.

In this post, we’re going to demonstrate how to unit test Cloudflare Workers, and their individual functions, with Cloudworker, created by the Dollar Shave Club engineering team.

Dollar Shave Club is a Cloudflare customer, and they created Cloudworker, a mock for the Workers runtime, for testing purposes. We’re really grateful to them for this. They were kind enough to post on our blog about it.

This post will demonstrate how to abstract away Cloudworker, and test Workers with the same syntax you write them in.

Before we get into configuring Cloudworker, let’s introduce the simple script we are going to test against in our example. As you can see this script contains two functions, both of which contribute to the response to the client.

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

async function addition(a, b) {
  return a + b
}

async function handleRequest(request) {
  const added = await addition(1,3)
  return new Response(`The Sum is ${added}!`)
}

This script will be active for the route worker.example.com.

After I’ve created a new npm ( npm init ) project in a new directory, I placed my worker.js file inside, containing the above, and created the folder test which contains worker-test.js. The structure is laid out below.

.
----- worker.js
----- test
      . worker-test.js
----- node_modules
----- package.json
----- package-lock.json.

Next I need to install Cloudworker ( npm install @dollarshaveclub/cloudworker --save-dev ) and the Mocha testing framework ( npm install mocha --save-dev ) if you do not have it installed globally. Make sure that package.json reflects a value of mocha for tests, like:

"scripts": {
    "test": "mocha"
  }

Now we can finally write some tests! Luckily, mocha has async/await support which is going to make this very simple.  The idea is straightforward: Cloudworker allows you to place a Worker in development in front of an HTTP request and inspect the response.

Before any test logic, we’ll place two lines at the top of the test file ( worker-test.js ). The first line assigns all property values from Cloudworker and our Worker script to the global context before every async function() is run in mocha. The second line requires assert, which is commonly used to compare an expected output to a mocked output.

before(async function () {
   Object.assign(global, new (require('@dollarshaveclub/cloudworker'))(require('fs').readFileSync('worker.js', ‘utf8’)).context);
});

// You will replace worker.js with the relative path to your worker

const assert = require('assert')

Now, testing looks a lot more like a Worker itself as we access to all the underlying functions used by Cloudworker AND the Worker script.

describe('Worker Test', function() {

    it('returns a body that says The Sum is 4', async function () {
        let url = new URL('https://worker.example.com')
        let req = new Request(url)
        let res = await handleRequest(req)
        let body = await res.text()
        assert.equal(body, 'The Sum is 4!')
    })

    it('does addition properly', async function() {
        let res = await addition(1, 1)
        assert.equal(res, 2)
    })

})

We can test individual functions with our Worker this way, as shown above with the addition() function call. This is really powerful and allows for more confidence when deploying complex workers as you can test each component that makes up the script. We hope this was useful and welcome any feedback.

Want to automatically deploy Workers directly from a GitHub repository? Now you can with our official GitHub Action. This Action is an extension of our existing integration with the Serverless Framework. It runs in a containerized GitHub environment and automatically deploys your Worker to Cloudflare. We chose to utilize the Serverless Framework within our GitHub Action to raise awareness of their awesome work and to enable even more serverless applications to be built with Cloudflare Workers. This Action can be used to deploy individual Worker scripts as well; the Serverless Framework is being used in the background as the deployment mechanism.

Before going into the details, we’ll quickly go over what GitHub Actions are.

GitHub Actions allow you to trigger commands in reaction to GitHub events. These commands run in containers and can receive environment variables. Actions could trigger build, test, or deployment commands across a variety of providers. They can also be linked and run sequentially (i.e. ‘if the build passes, deploy the app’). Similar to many CI/CD tools, these commands run in an isolated container and receive environment variables. You can pass any command to the container that enables your development workflow.

Actions are a powerful way to your workflow on GitHub, including automating parts of your deployment pipeline directly from where your codebase lives. To that end, we’ve built an Action to deploy a Worker to your Cloudflare zone via our existing Serverless Framework integration for Cloudflare Workers. To visualize the entire flow see below:

To see some of the other actions out there today, please see here.

Serverless applications are deployed without developers needing to worry about provisioning hardware, capacity planning, scaling or paying for equipment when your application isn't running. Unlike most providers who ask you to choose a region for your serverless app to run in, all Cloudflare Workers deploy into our entire global network. Learn more about the benefits of serverless.

The Serverless Framework is a popular toolkit for deploying applications that are serverless. The advantage of the Serverless Framework is that it offers a common CLI to use across multiple providers which support serverless applications. In late 2018, Cloudflare integrated Workers deployment into the Serverless CLI. Please check out our docs here to get started.

If you run an entire application in a Worker, there is no cost to a business when the application is idle. If the application runs on our network (Cloudflare has 165 PoPs as of writing this), the app can be incredibly close to the end user, reducing latency by proximity. Additionally, Workers can be a powerful way to augment what you've already built in an existing technology, moving just the authentication or performance-sensitive components into Workers.

Configuration of the Action is straightforward, with the side benefit of giving you just a ‘little bit’™ of exposure to the Serverless Framework if desired. A repo using this Action can just contain the Worker script to be deployed. If you feed the Action the right ENV variables, we’ll take care of the rest.

Alternatively you can also provide a serverless.yml in the root of your repo with your worker if you want to override the defaults. Get started learning about our integration with Serverless here.

Your Worker script, and optional serverless.yml are passed into the container which runs the Action for deployment. The Serverless Framework picks up these files and deploys the Worker for you.

All the relevant variables must be passed to the Action as well, which include various account identifiers as well as your API key. You can check out this tutorial from GitHub on how to pass environmental variables to an Action (hint: use the secret variable type for your API key).

Support

The repository is publicly available here which goes over the configuration in more technical detail. Any question/suggestions feel free to let us know!

Mesosphere DC/OS provides application developers and operators an easy way to consistently deploy and run applications and data services on cloud providers and on-premise infrastructure. The unified developer and operator experience across clouds makes it easy to realize use cases like global reach, resource expansion, and business continuity.

In this multi cloud world Cloudflare and Mesosphere DC/OS are great complements. Mesosphere DC/OS provides the same common services experience for developers and operators, and Cloudflare provides the same common service access experience across cloud providers. DC/OS helps tremendously for avoiding vendor lock-in to a single provider, while Cloudflare can load balance traffic intelligently (in addition to many other services) at the edge between providers. This new offering will allow you to load balance through the use of Argo Tunnel.

Cloudflare Argo Tunnel is a private connection between your services and Cloudflare. Tunnel makes it such that only traffic that routes through the Cloudflare network can reach your service.

Cloudflare’s lightweight Argo Tunnel daemon creates an encrypted Tunnel between your origin web server and Cloudflare’s nearest data center — all without opening any public inbound ports. In other words, it’s a private link. Only Cloudflare can see the service and communicate with it, and for the rest of the internet, the service is reachable only through the hostname configured on Cloudflare. Check this out if you’d like to learn more.

By using Argo Tunnel, DC/OS is able to load balance your traffic to any of your hosts, wherever they are running on Earth, in any cloud provider! Need more instances in Paris? Just launch them! Are instances more affordable in a specific provider? Just launch them there, and thanks to Argo Tunnel and DC/OS your traffic will be directed to exactly where it belongs.

In order to use this application in DC/OS you must have a zone on Cloudflare with the Argo service enabled. Argo can be enabled for any plan type and is billed on usage. Because this application requires the use of a DC/OS ‘secrets’ the Enterprise version of DC/OS is required. To get started on Cloudflare please see here and sign up for an account. To do the same with DC/OS, please see here.

Argo Tunnel is the fast way to make services that run on DC/OS private agents (that are only bound to the DC/OS internal network) accessible over the public internet.

When you launch the Tunnel for your service, it creates persistent outbound connections to the 2 closest Cloudflare PoPs over which the entire Cloudflare network will route through to reach the service associated with the Tunnel. There is no need to configure DNS, update a NAT configuration, or modify firewall rules (connections are outbound). The Argo Tunnel exposed service gets all the benefits offered by the Cloudflare network (e.g. DDoS protection, CDN and performance, TLS, etc.).

The Cloudflare Argo Tunnel Service is available from Mesosphere DC/OS catalog.

Configuration of the Argo Tunnel requires you to specify three things.

• Cloudflare Hostname - The DNS name of your service on the Cloudflare network. This is the address where you wish your service to be available from on the Internet. (Note: adding a zone to Cloudflare is extremely simple, you can get started here (link: https://www.cloudflare.com/plans/)

• Local Service Url - The local URL of the service that you want to make available, on the machines running Argo Tunnel.

• Load Balancer Pool - The load balancer pool you want the service to be part of. Use any value you like, keeping the value consistent for tunnels you wish to load balance traffic onto as a unit. Inside Cloudflare you can manage how your traffic is balanced between and inside your pools.

Assuming you do that setup for a service in a West Coast DC/OS cluster and an East Coast DC/OS cluster, with a respective us-west and us-east LB pool, then you end up with a Cloudflare load balancer globally balancing traffic between these clusters. The load balancer can be configured to do geosteering, which you can learn more about here.

For more details see the DC/OS Argo Tunnel documentation. We hope this partnership is a meaningful step towards a simple multi-cloud solution for DC/OS customers.

To sign up for Cloudflare click here and to sign up for DC/OS click here. This partnership between Cloudflare and Mesosphere we hope will help you drive private secure and performant multi cloud deployments