I love Cloudflare, but these Image products are a black mark on their reputation.
Every point the author says is 100% correct. I'll add one more point, which ended up making it a total non-starter: you can't import lots of images because their rate limits are so pernicious. If you have tens of thousands or millions of images, keeping within their single digit per second rate limit, which appears to be totally non-negotiable, makes it impossible to add images at any scale.
They have another product called Cloudflare Images which can work from Workers: but here the pricing is almost absurd and from the data they show on their dashboard, they only cache a tiny percentage of the requests. This means you end up paying a lot more than makes sense.
Just a perspective from a user point of view, but I hate Cloudflare. All I remember about them is staring at their DDoS protection page for multiple seconds before a site's content loads.
EDIT: I'd argue that DDoS protection should be provided on the network level, not on the application level by some Javascript on a page. So yes I do hate Cloudflare for providing that service.
I’ve long taken Cloudflare to task for granting DDoS protection for countless DDoS-for-hire services, to no avail. I’ve maintained that Cloudflare has a blatant conflict of interest here, and that the DDoS-for-hire industry would quickly blast itself into oblivion because the proprietors of these attack services like nothing more than to turn their attack cannons on each other. Cloudflare has steadfastly maintained that picking and choosing who gets to use their network is a slippery slope that it will not venture toward.
Cloudflare is pretty great in a lot of ways. They have a lot of promising products, and I have never had problems with their reliability (and I've seen it handle billions of requests).
Thanks for the feedback. I'm on the CF Images product team.
We will allow the download of the original images, it is actually one of the next features coming up. Also we will introduce webhooks and Images Analytics next.
Thank you. If there's any other feedback you could take from this, please know that I've submitted a similar feature request for point #6, so that I could know the ID of the image from the direct creator upload. Without that, a malicious user of mine could possibly create many millions of images, and I would have no way of knowing who it was that created the image, and no way of knowing which images to delete or track.
I think Images could greatly benefit from having a tag/label system that allows you to decorate it, similar to how enterprise cache tags was implemented. That way, it is trivial to do things like "delete by user id X" as well as covering your use case.
Honour EXIF as well as sidecars for tags. Use one of the defined tag syntaxes and state which one you honour.
Approximate date in images is a huge issue. There's a range of ways to express uncertainty to date, not after. not before. circa. between. year good month uncertain. If you invested in this space, you could help simplify the thinking. Ramming it into specific YYYY:MM:DD:HH:MM:SS values is really bad.
Google is a bad actor here in photos: they don't re-index on tag modification except for very specific changes and its opaque and poorly documented. If you do better it has good qualities about market and mind share.
"it is actually one of the next features coming up" is one of the most annoying things I hear from enterprise companies that I have issues with. I have received this response and waited for the feature for over a year or have never seen it released at all.
Thank you for the response, but, at the end of the day, people are going to judge Cloudflare on how quickly and accurately they can solve these issues.
I assure you it's not just you. I see it from the other end as well. Not long ago I had a client shout "I don't want to hear about your roadmap!" and grab his team and walk out of a meeting. We really shouldn't have used that terminology there, since the feature they needed was actually already in beta test with a few friendlies, we could have added them to the beta test cohort on the spot, and demonstrated it in their account during the meeting.
(Personally, I'm kinda glad we didn't. They were without doubt the sort of customer we should have already fired...)
I can empathize with the customer here. I have also seen it from the other end, working for a large and slow SAAS organization. I see PMs always wanting to show the customer the "roadmap" because they think it somehow appeases the customer and calms their wrath. The wiser customers know that a roadmap is not a promise, and will take it with a huge grain of salt. I have grown to almost despise the word or mention of it. Quit with the meetings and compliance reviews and politics and just get stuff done for god's sakes.
This is exactly where that customer was coming from. Many many broken promises from their previous vendor about essential features "being on the roadmap" for 2-3 years without ever seeing the light of day. (And we knew that was one of the biggest reasons we poached them away.)
I thought Cloudflare was going to win the image hosting/serving/resizing game based on their original blog post, but that doesn't seem to be the case.
I kept getting frustrated with the complexity and changing costs of solutions out there, so about a year ago I launched https://www.simplefileupload.com. It's a super easy, flat rate cost solution to quickly allow users to upload images and files. It provides a customizable upload widget and serves files via a CDN and firewall to protect against attacks. It doesn't have query param image resizing yet, but it's coming!
Cool to see this here! I've been following your journey on the Software Social podcast [0] and it's awesome to watch the project progress. I also really enjoy that the podcast is not all sunshine and rainbows, like you actually talk about the ups and downs and it's great. We need more like it.
Isn't it a bit too easy to exploit this? Like by maliciously uploading tons of data to the account of a site using this service in order to exceed their limit and hence break their file upload process.
Wow, this looks so awesome! Really simple UI too — gonna have to give this a try. I was just struggling with some client-side image upload stuff last week, and I love the idea of doing the full service integration from client to backend as a product.
BTW - I’m part of the dev advocate team at Cloudflare, would you want to chat sometime about your experience with Images? Definitely would love to hear your perspective as a dev on what could be better!
What Colleen has built is indeed quite simple to use.
You just add the JS snippet, SFU handles all the storage and just returns a URL.
And bonus points, it's directly uploaded to S3. From the documentation: "Simple File Upload uses direct uploads. In a direct upload, a file is uploaded to S3 from a user's browser, without first passing through your app."
oh its leenyburger! loving that you are building it in public on your Software Social podcast. listening to you two over the past year has been really educational.
Just FYI, your front page is broken in Firefox with default uBlock Origin settings. Considering potential audience, you might want to fix that. The pricing page is fine.
I've run into a lot of these issues using it and I've even reported them on every available channel.
The original image is my biggest complaint. I was making a service where users would want to batch retrieve what they've uploaded. No response on the forums to that.
Also hit the CORS issue, so rather than fetching an image and loading it into a canvas I have to use a fake image element. This makes the canvas untrusted.
Delete was also annoying. I wanted to blow out my dev environment and there was no way to just purge everything.
I kinda stalled, was going to try S3 since the original image thing was such a breaker for me. I was vocal about all these same issues, making my own threads and bumping others in the forum.
"Images is a single product that stores, resizes, optimizes and serves images"
Because it's not just a CDN but does many more things. With this product description (taken from CF blog post) I'd expect it to behave like a storage bucket containing the files (including the raw file), with an image resizer and CDN attached.
You're very welcome! I posted this on the CF Developers discord as well. Really hoping that I'll be able to fully migrate over to CF Images in the not too distant future :)
We were charged $10k for the first month of use and immediately reverted the implementation. CF was kind enough to refund us since we're still an early stage co. It would be great if pricing was more reasonable
I remember there was another article about image uploads and content moderation (here: https://news.ycombinator.com/item?id=28684250), essentially saying that if you create a open uploading service, you WILL start getting lots of spammy images / abuse.
CF Images always seems like a LOT more $$ than other image hosting tools out there. What other service did you end up going with?
I often use Bunny CDN where it's $10 a month for UNLIMITED image alterations. They charge half a cent per gigabyte on traffic of the post processed image (in their bulk tier) along with 1 cent per gigabyte for storage.
The nearest competitor is likely over 10x more (Caveat: For the workloads I've applied this on).
they also removed the private images part, and pivoted towards becoming a "social network" (several years too late). Honestly no idea how they stay alive.
Also honestly no idea why they never jumped on the NFT bandwagon.
Oh, they're also apparently a tiny team (<50) too, so that probably helps
Lucky for you that you don't check your bills on a quarter basis (3 months). It could have been another story to be reimbursed and the bills might have more than triple.
I had a client a few years ago who was using another service for image hosting, and they were getting charged through the nose for it. This is before cloudflare had their own image CDN style service. The client's app made heavy use of URL based image transforms. And we didn't want to lose that - so it seemed like they were a little stuck.
The website itself was already using cloudflare's CDN. So I added a simple cloudflare URL rule to redirect all requests hitting /images/XXX to the 3rd party image hosting service. Within a month our client's image hosting bill dropped from $~10k/month down to about $90/month, which I felt great about.
I did made one terrible mistake though - I forgot to tell our client about the configuration change. So cue a monday morning panicked phone call from our client when they got their bill, asking what on earth was happening that caused all their web traffic to disappear overnight. They thought (based on the bill) that their website must be broken and they were freaking out about it! Oops!
The client was using an image host which supported image transforms. They uploaded all their images there and were using a lot of image transforms from that host on their website. So, HOST/img/123?scale=1.3&color=greyscale type business. They were paying per image loaded from the site.
We tucked cloudflare in front of the image host using a URL rewrite rule. Cloudflare's cache reduced the number of requests made to the image host by 99% or something.
I followed Matthew over from project honeypot and they sent me a T-shirt for being one of the first 100 users on cloudflare. I’m sure if I wanted I’d have gotten more help. Thing is, you’re right, I’m a paying customer and even though Pages is a beta product waiting two months for an intelligent response for a documented issue seems extreme. Fortunately a more mature product exists on Netlify. I just pay them for services.
hey, sorry about that delay in response. Following up internally about your ticket, so you should hear back very soon.
Changing your repo name shouldn't break the project nor prevent subsequent builds. It's just the Pages dashboard will still show the old repo name - so the only way to update that is to delete the project and make a new one: this is a bug we're working to fix!
The Gitlab integration for Pages is also pretty immature. It doesn't appear to currently work with Groups/Subgroups. I've been back and forth with people on their Discord for maybe a week now trying to just get it setup for a test.
I was very excited about CF Images, but after doing some basic napkin math the pricing was way more than expected. That, coupled with some of the other limitations you mentioned, had me abandon CF images pretty quick!
that's probably the logical continuation of video hosting - if you upload something to, say, YouTube, you also don't expect to be able to retrieve the original video from there. It may be a high-quality version, but it still gets reencoded on upload...
Well, Vimeo does allow downloading the original video. When I think YouTube I think of a Video Social Media network. Similar to how I don't expect to download the original picture on Instagram, Snap, or Facebook.
Where-as Vimeo is closer to a video hosting service.
Doesn't always seem to be the case though, like you can't download the original video of the 'The Batman' trailer (https://vimeo.com/633805668) anymore for example?
Used to be available (ProRes Video (apch) 3840x2160 23.976fps 685 mbit/s [V: prores hq, yuv422p10le, 3840x2160, 685726 kb/s]).
Slightly higher quality than the one they published on youtube (judge for yourself).
"5. Lack of dynamic resizing, only 20 “variants” allowed"
Best practice when it comes to images on the web is to use a fixed number of sizes. Why they limited it to 20 I do not know though. You should never allow dynamic image resizing since it is commonly used in various attacks.
Cloudflare is industry leading when it comes to facing those kinds of attacks, though, and it's supported in the "Cloudflare Image Resizing" [0] product.
Also, using a fixed number of sizes might be best practice when it comes to a website you have full control over, and can plan the content for. When it comes to user-generated content, where you want to give the user the opportunity to select a custom crop for an image, you don't necessarily have that kind of control.
The alternative we considered was doing the crop on the client before uploading the image, but that ensures loss of information, and makes it impossible for the user to edit their selection at a future time without re-uploading the image.
It's a common DoS vector. If you limit the allowed sizes, you can predict your min/max for compute, storage, cache, networking, etc. If you allow arbitrary resizing, the client can iterate indefinitely, doing things like "give me 1x1, now 1x2, now 2x2", which will tie up your compute resources, eat up storage, push legitimate data out of your cache, etc.
Resizing an image is computationally intensive (at least compared to the average HTTP request). You can sidestep that by using caching: resize once, then serve the cached version from then on.
Dynamic resizing opens you up to a DDOS attack, essentially: someone would request the image at 1x1, and 1x2, and 1x3... you get the idea. But yeah, if there was anyone able to mitigate that risk via other means you'd think it would be Cloudflare.
I worked with sites that had performance issues because of attacks against dynamic image scaling in Cloudflare (scaling probably done with workers). Services like Cloudflare does not in general protect against service design issues. I try to explain that to people all the time. I also worked with another provider where a monthly bill got 5 times higher one month because images were requested at many different large sizes.
Yeah, I've come across sites that allow arbitrary resizing via dimension numbers in the URL. Seems like it would be easy to CPU ddos by submitting random numbers in those fields.
Huh. I don't understand how this would effect a site using Cloudflare Images. It seems like maybe a DDOS against Cloudflare itself, but I don't see how it would be a problem for your site. But you say it was, so.
But okay, thanks for providing more context. I have not used Cloudflare Images at all, so I don't really know, just trying to make sense of it.
I hear you Daniel. We have built a no nonsense image (and video) optimization service that addresses all of the issues and does more.
#1. Simple pricing [1]. We only charge for optimize bandwidth out. No other charge.
#2. Complete analytics [2] on number of images served, bandwidth usage, response times, formats of images served etc.
#3. You keep original images in your own storage [3]. We only cache it the first time we fetch an image to resize. This is to prevent any lock-ins and easy integration.
#4. You can easily setup any custom headers including CORS for all images from a dashboard.
#5. Complete dynamic resizing available with a simple API. As noted by CF officials below they can’t do it because they are a DDoS prevention company first. We are a media processing company first.
#6. No direct upload necessary. Our performance will be top of the line regardless of where the original images are stored.
#7. Max input size in free plan is 8192x8192 pixels. It’s even higher in paid plans. Plus all image formats including animated GIFs, Lotte, SVG are accepted and optimized when possible.
#8. Batch deletions not required as we don’t own originals
#9. We are super responsive to support and help our customers. We will let our reviews speak for that.
Hi, fantastic product! It seems that you also do video transcoding - how are the limits there? I can't find explicit info alluding to video in your pricing page.
Hi, Thanks for checking out. We are planning to launch new pricing for video around mid December. Ping me over support chat and I will give you early access.
I was always resizing images myself and storing separate versions before I heard about Cloudflare Images. The CF implementation looked a bit confusing and expensive though and I ended up using Bunny.net and it's been fantastic. Incredibly easy to use, the API is dead simple, you can pass in different parameters live and it will manipulate the source image and cache it for future requests. It's cheap and support is top notch. Highly recommend people check it out if they're looking for something like this. It's so much easier sending up the original file and being able to change dimensions on the fly.
Update your UI and now thumbnails need to be 400x400 instead of 250x250? Just update the parameters and you're done. No need to manually resize your whole back catalogue as they'll be done on demand.
The Argo (optimized routing to the origin) pricing makes no sense to me either. Cloudflare charge for bandwidth when you enable Argo, but on ALL requests, not just those that hit your origin. There's actually zero change in routing for the cached requests - the client still hits the nearest CF datacenter, but now you're being charged for bandwidth on every cache hit when you used to pay nothing.
I like Cloudflare but some of the pricing decisions on the premium features definitely leave me scratching my head.
I'd also add to your feedback by saying that there isn't a "Simple" way to integrate it into existing CMS's or even static sites, a plugins for the top 3 CMS's would be nice + an "imgbot" equivalent for static sites.
Imgix has been quite nice: unlimited variants, pricing per master image plus bandwidth charges, and you can keep your images on S3.
They even contacted us about setting up a custom agreement when they noticed we were going over the allotted plan.
Man sounds like their images product needs a "let's take a step back and rethink why we hit some of these limits and talk about what we can do about it".
Something fundamental seems to have gotten out of hand when it comes to the entire offering.
When I first saw this product announced, I immediately wanted to replace my manual solution with it. I’ve been putting it off because other work had to be done, but now that I read this, I think I’ll stick with my current workflow for now.
Having a CDN in front which could do this for me is what I’ve been dreaming of, so I can simply have an images folder with the unaltered images instead of all those variants. But what I want isn’t always what I need.
Maybe what I need is something like a reverse proxy that can generate the variant on the fly when it is requested by the browser through the srcset.
Unless you're running something that's mostly images, I'm a fan of pregenerating variants of images for static sites since storage has become so cheap. However, I think the best way of doing that is to actually generate the variants as part of the build step, the way that Next or Gatsby can. Hugo also seems to have some support for image processing [1] so it may be possible to put something together using only Hugo. It increases build time, but a build cache should fix that.
Thanks for a great writeup. We are happy with thumbor, but I was considering switching to
CF images, since we upgraded to Enterprise. You saved me a bunch of time and pain!!
As a side note, after upgrading to Enterprise, I feel quite disappointed with CF. Caching and the core features work great, but other features feel much less mature, enterprise support appear slow and not that on top of things. Sorry for the rant, but needed to vent a bit :)
Yes, by far my top choice in OSS land for image manipulation. You would probably want to couple it with a edge worker to do things like accept handling (what format to return for the same url), whitelisting formats and so on.
I wrote a pretty comprehensive cloudflare worker for this years ago I should look at open sourcing..
Cloudinary has two parts
- a Digital Asset Manager for storing content
- an service for optimising / resising images (and video) that then uses Cloudflare, Fastly etc as a CDN
Akamai, Cloudflare, Fastly all already have image optimisation services, so if you're using them already why use Cloudinary.
The DAM piece is more of an issue as most CMSs aren't great on the asset management front but looking at commerce etc platforms they're getting better
Cloudinary does a lot more than asset management, the depth of at-request-time functionality you can get just by URL params alone (like cropping with face detection...) is untouched by any of the cdn offerings of "let me resize/compress that for you".
The only thing that is shitty about the cloudinary model is the bandwidth costs. If someone could combine the functionality of cloudinary (it is genuinely unmatched in the space) with the cost of cloudflare... I'm in. They're even doing a great job on video editing (changing encoding format, bitrate, container, splicing in audio, cropping, thumbnail...) again using the same "just change the url and it's done" approach.
Saying CDNS will eat this by offering mediocre asset management is not apt.
Cloudinary is an end-to-end solution for managing images and videos, for developers. The CDN and optimization parts are tightly coupled with the digital asset management: e.g. if you change an image, the system knows to invalidate the relevance cached images, and is CDN-agnostic. So no, CDNs are not competition, but rather good partners to Cloudinary.
Regarding the DAM: CMS and Ecom systems are indeed getting better, but media assets you upload to them become siloed in the CMS. Cloudinary acts as a headless DAM that you can embed in any CMS and use as a single source of truth, relieving a lot of the pains of handling media files and their versions.
I am working on an alternative service for the optimized images and deliver them over a CDN [1], for the images it generates a series of down-scaled images and provides a helper script to get the right image.
Right now all the documentation and examples are focused on NodeJS [2], but I am working on examples for Dart, Ruby and Python.
Some of the features are:
- Optimized images
- Custom domain
- Public and Private files over a CDN
- Upload widget, API, UI, dashboard and webhook
- Bulk delete and bucket manipulation
- CORS configuration
I am working on a couple features for the private files and image handling (based on the feedback from the users), let me know if you want to give it a try!
Image Resizing is technically a separate product, so I apologize if this is off-topic, but it appears to be missing the most useful `fit` mode – something like `fit=cover-scale-down`. I never want to enlarge an image on the server, since I can do that client-side. If I request a version with the dimensions 512×512 (square), but the source image is only 400×600, there should be a way to get a resulting image of 400×400. Am I misreading the docs?
https://developers.cloudflare.com/images/image-resizing/url-...
Edit: Changed suggested name of fit mode for clarity.
I think "scale-down" is the closest to what you're after. If you have a 400x600 original, and request 512x512, you'll be served a 341x512 image. This maintains the original image's aspect ratio, and a fits within the requested (512x512) size.
I want to maintain the aspect ratio of my crop, not that of the source image. Perhaps `fit=cover-scale-down` would be a more appropriate name. In other words, I always want a square image <= 512px wide. I think this is a very common use case.
fit=crop and fit=cover only work well if the source dimensions are greater than 512×512. If either dimension of the source is smaller, the behavior is useless.
fit=cover will return a square (as requested), but will enlarge it (which you never want because it wastes bandwidth).
fit=crop will cut off excess pixels if either dimension exceeds 512, but it does not always return a square. (And contrary to the docs, it does not behave like fit=scale-down.)
For instance, you configure your CloudFront distribution to source from the Image Transformation service. You configure your Image Transformation service to source from your S3 bucket.
This seems like the best of all worlds to me. Does this exist?
Yes, that's totally the description of Transloadit https://transloadit.com/
You import from your own storage and export wherever you want also, we handle the encoding and transformation for you. We don't support CloudFront yet, but we support export/import from S3 and a lot of other providers.
Hey We at Gumlet [1] do this. By default we only work with your own storage for originals (image or video). Configuring your own CDN is also an option if your volume is large enough (> 1TB data out per month). It's super simple to configure with none of the issues mentioned in the article. Feel free to reach out to us over website chat for more information.
Does Cloudflare just write blog post upon blog post shitting on other companies, or are these examples just coming up now because when it rains it pours? These seem like embarrassing posts to have highlighted as well; the fake benchmark one and this hypocritical egress one.
It's easy to throw potshots from the stands, but from the article the whole thing sounds less than half-baked. 25% baked, maybe. One wonders what the spec and milestones are, if in fact it wasn't simply and plainly rushed out for business reasons.
Off topic, but I couldn't read this because the blog is in dark mode and doesn't offer a light mode. For a lot of people with astigmatism, dark mode is simply unusable for text heavy sites.
There are objective reasons why dark mode is worse than light mode, but I think anyone should be able to pick whatever mode they prefer.
I have no data to back this up, but I suspect the main reason dark mode is so popular these days it's because there are a lot of users using devices in poor light conditions. The second big reason is probably more cultural, as dark mode looks more modern, unlike these damn boomer UIs from the 90s (sarcasm).
Some people argue about energy efficiency and OLED, which is true, but that seems like a niche use case to force dark mode on all your users.
Thank you for bringing this to my attention, I wasn't aware that was even a thing :)
It's not in "dark mode" though, it's simply a dark theme, and those have been around since forever. I'll look around for a theme that supports both when I get the time, but until then I echo the suggestion of a sibling comment to use the reader mode.
> dark mode looks more modern, unlike these damn boomer UIs from the 90s (sarcasm).
At least for me dark mode brings back all the feelings of the 80s text UI, which was predominantly white/gray on black or perhaps white/yellow on dark blue - and quite readable. (I also recall that in some domains MDA monochrome monitors with green or orange on black were popular).
Every point the author says is 100% correct. I'll add one more point, which ended up making it a total non-starter: you can't import lots of images because their rate limits are so pernicious. If you have tens of thousands or millions of images, keeping within their single digit per second rate limit, which appears to be totally non-negotiable, makes it impossible to add images at any scale.
They have another product called Cloudflare Images which can work from Workers: but here the pricing is almost absurd and from the data they show on their dashboard, they only cache a tiny percentage of the requests. This means you end up paying a lot more than makes sense.