Hiding spaces behind cloudflare

Posted November 23, 2017 14.1k views

I’m wondering if it is possible to use spaces behind the cloudflare proxy for cost and security reasons.
As far as I understood, this would involve the following:

  • Set up something to deny all requests to from non-cloudflare IPs
  • Set up a custom subdomain on cloudflare that points to the space

Can spaces be used this way?

  • Judging by the complete lack of responses, I’m assuming this isn’t possible right now? Maybe it could be added in the future?

  • Hi there - I’m the product manager for Spaces. There is no way to do the 1st thing (limit Spaces access by IP) today. Some CDNs (not sure about cloudflare) will let you input an access/secret pair so you can limit reads that way. Is that what you’re trying to accomplish or is it a hard requirement to block at the network level?

    Re: the 2nd thing, this works with any CDN and Spaces. However, the Cloudflare free plan doesn’t allow host header re-writes, which what is required to make this work today. We are working on making it so that customers can do this with the cloudflare free, too. My hope is that we can release this in early Q1.

    Let me know if you have other feedback or can share more about your use case. Thanks so much for leaving the comment/question.

  • My use case is actually fairly simple, I’m looking to run the dynamic part of my site on a droplet, store all the static files in spaces, and hide the whole thing behind cloudflare:

    Unfortunately I’ve not found anything on cloudflare about giving it a special access key. They always recommend you to deny all requests that do not come from these ip addresses, as early as possible: . Otherwise someone could simply bypass cloudflare by requesting the file from directly and cause an unexpected high invoice using bot downloads.

    It looks like host header re-writes are limited to enterprise customers, not just paid plans, so this would not be useful for most people. But since you’ve already got custom domain support coming soon, the second part is solved.

  • Show 1 more comments

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

Submit an Answer
9 answers

Not sure if this is still an issue here for folk. We’ve recently done this for 4 separate Spaces

  1. Create Space + CDN
  2. Create a desired CNAME for your DO CDN
  3. use Cloudflare’s tool to create origin server self-signed SSL Cert specifically for the CNAME created in step 2.
  4. Use Spaces CDN option to add new subdomain certificate. Use the certificate details from step 3.
  5. You can then proxy via Cloudflare.
  • I signed up just to say thank you for this, it works :)

  • Works perfectly, thank you.

  • This allows using Spaces behind Cloudflare, but not hiding it behind Cloudflare. Requesting a non-existing file from a Space set up this way causes Spaces to print the bucket name to the user, which can then be used to bypass Cloudflare and bot download files directly, causing you a massive bandwidth bill.

    • Sure you can have bots download either way, so what’s the issue? If anything, this reduces the likelihood of it going direct to the CDN endpoint.

      I’m not sure I get your point.

      • The point is that bots hitting Cloudflare doesn’t do anything, while bots hitting the origins behind Cloudflare is quite a problem.

        • But your original question simply stated: “if it is possible to use spaces behind the cloudflare proxy for cost and security reasons”

          Now you want to make it impossible to “know” that a resource is hosted within Spaces.

          You said it’s “quite a problem”. What’s the problem you’re solving that you’re actually facing today? Or is it a hypothentical concern about “bots maybe able to nom nom at my bandwidth”? - which is the same in practically all CDN scenarios. The solution I provided here actually does mitigate some of it, unless you have a particularly clever bot with an axe to grind.

@johngannon just wondering if anyone has figured this out. pointing a subdomain like to the Digital Ocean space’s domain would be great

We’re working on it (custom domain support delivered via a new endpoint that will talk HTTP) – still targeting early Q1.

  • Will using a custom domain completely hide the name of the space? That would mostly solve the problem of not being able to deny non-cloudflare traffic, simply name the space some random long string and noone will ever find it outside the custom subdomain that goes through cloudflare.

The issue is that Cloudflare requires the bucket name to be the exact domain you are hosting and DigitalOcean has prevented bucket names with dots.

You can recreate this on s3, create a bucket www-example-com, enable html hosting and get the url for the html files (not the s3 bucket url). Create the cname in Cloudflare for, and you will get the same error from s3: NoSuchBucket

Go back to s3 and create a bucket, enable html hosting and get the html hosting url, and update the cname, the site will work.

This is the exact same issue with DO Spaces, however because Digital Ocean prevented bucket names with dots, using Cloudflare in front of a Spaces bucket will not work.

It would be as simple as Digital Ocean allowing bucket names with dots to fix this.

  • Exactly! If they have similar S3 functionality.

    Can you enable periods in the spaces name so that we can use a CNAME in cloudflare and that’ll allow us a custom spaces name so long as our spaces name matches exactly the cname and domain. EG on a domain CAME images and entry
    This would be the most expedient solution… lots of people don’t know this is possible with AWS S3 but it’s there in their docs.

@tannerchung we just enabled this in Spaces:

Hope it’s what you are looking for. If you have feedback please let us know!

  • @johngannon Hi, this does indeed work to access a space through Cloudflare! However, if a non-existent file is requested, we get a response like this:


    As you can see, that easily allows one to reconstruct the original url:

    Which can now be used to bypass Cloudflare caching and bot detection and cause unexpected costs.

    If you could just remove that <BucketName> entry on publicly acessible error messages, or provide an option to remove it, that would be the last missing piece to safely use Spaces behind Cloudflare without the potential to leak the origin and without having to use Workers to work around the issue.

I am noticing that DO CDN is still quite slower compared to cloudflare and also for management and security reasons still make sense to keep cloudflare in front of all domains including the spaces domains. With S3 I used this approach mentioned @DavidLevy , but cant make it work with DO Spaces. :/

I think Zeblote’s comments describes very well the thing that he wants to do, I’m looking myself for the same thing and really haven’t found any real answer.

Basically the thing is:

1.- Store web application on droplet, using a cdn like cloudflare point to the application by the domain ‘’ and enjoy benefits from using cdn.

2.- Store all static files (.jpeg, .png, .css, .js, .mp4, etc.) on spaces. However by doing this anyone could access directly the files, consuming bandwith and resources of the spaces bucket, or simply perform malicious actions directly on the bucket itself.

3.- By hiding the bucket behind a cloudflare cdn I think he means (at least from my understanding), is that he wants to create a cname for '’ alias '’ wich points to the spaces bucket therefore the files stored at the bucket. So instead of accessing the files by '’ we can access them simply like '’, wich is easy to remember and better brand representing than the first one, and enjoy benefits from using a cdn.

Nevertheless using a cdn brings a lot of benefits to the table, like security, file caching, etc…

In summary:

'’ in cloudflare points to web application ip in droplet.

'’ in cloudflare points to '’ in spaces.

Is there an actual way of doing this?

johngannon please give real answers.

  • They’ve launched a beta for the new “custom domain” feature since I asked this question, however I was not able to get this working with that either. Spaces will always respond to cloudflares requests with “404 NoSuchBucket” for no appearant reason.

    Followed by a very long support ticket (the messages have to be read bottom to top)

    So, it looks like we can still not use spaces behind cloudflare. Why? Noone knows. It returns the file to a request from my browser and 404 to an identical request from cloudflare. Grey cloud has the same result as not using cloudflare at all so that’s not really helpful either.

    I’m now thinking of using droplets with nginx to handle requests from cloudflare and forward the stuff from spaces, supposedly bandwidth between spaces and droplets in the same datacenter is free.

    • Yeah the forwarding stuff for me is a no go, I really (please please) expect my services to grow and eventually will have to load balance my servers, I can imagine the forwarding stuff with load balancing beeing a real headache.

      After hours and hours of trying I finally gave up with spaces, I really really wanted to go with spaces because I absolutely love DO droplets and wanted my application to be in the same platform. But this feature is really important for me and my brand and for future scalability purposes.

      I’ve set this up in google cloud storage and was a no brainer, you basically verify ownership of your domain, create your storage instance (name it to ‘’ as has to match the url of your domain. The instance has to be called '’ and the cname of your DNS has to be 'static’ and your domain '’ because they have to match), create cname 'static’ (or whatever you want) of your domain '’ (or whatever your domain is) in cloudflare to point to the google cloud storage URI ('’ by the time of this writing) and thats really it, now you can simple point your static assets to '’.

      Until DO doesn’t solve this I’m stuck with google cloud storage… :(

      I’m keeping my servers in DO droplets by the way, I absolutely love them!.

      • That’s an option. But it doesn’t look like a very good one:

        Running a few identical forwarder droplets costs you $5/TB. Miscalculating your scaling for a month, and paying 100% of the bandwidth as overages, costs you $20/TB.

        …meanwhile google cloud storage eats a whopping $80 to $120/TB for no reason!

        And since this whole thing sits behind the cloudflare cache, you can probably get by with just a small number of droplets.

What you could do today is setup a reverse proxy using Nginx (or any other frontend server), rewriting the requests from something like to and put cloudflare in front of, so you should never pay for exceding transfer usage (as included one should be more than enough)

is it still necessary because you can enable cdn in spaces?