Building https://www.gumlet.com

Streaming video is still hard to do for a developer today and we are solving that with scalable and cheap infra for streaming.

This change finally helped our company move to typescript.

Just converted many of services to TS and some are WIP. It’s a big win.

Jason, here is a story about how much your work impacts us. We run a decently sized company that processes hundreds of millions of images/videos per day. When we first started about 5 years ago, we spent countless hours debugging issues related to memory fragmentation.

One fine day, we discovered Jemalloc and put it in our service, which was causing a lot of memory fragmentation. We did not think that those 2 lines of changes in Dockerfile were going to fix all of our woes, but we were pleasantly surprised. Every single issue went away.

Today, our multi-million dollar revenue company is using your memory allocator on every single service and on every single Dockerfile.

Thank you! From the bottom of our hearts!

indeed! most image processing golang services suggest/use jemalloc

the top 3 from https://github.com/topics/resize-images (as of 2025-06-13)

imaginary: https://github.com/h2non/imaginary/blob/1d4e251cfcd58ea66f83...

imgproxy: https://web.archive.org/web/20210412004544/https://docs.imgp... (linked from a discussion in the imaginary repo)

imagor: https://github.com/cshum/imagor/blob/f6673fa6656ee8ef17728f2...

Yep, imgproxy seems to use libvips, that recommends jemalloc. I was checking and this is a funny (not) bug report:

https://github.com/libvips/libvips/discussions/3019

Hello, libvips author here. This is probably the canonical thread about libvips and memory fragmentation, and the funniest graph:

https://github.com/lovell/sharp/issues/955#issuecomment-5458...

(that specific graph is for switching from glib to the musl memory allocator, but jemalloc gives a very similar result)

Those three all use libvips as the image processing engine, fwiw, so it's maybe not a very wide survey.

libvips is fairly highly threaded and does a lot of alloc/free, so it's challenging for most heap implementations.

We use libvips as well sir. We can't overstate how much we benefit from your work!

I really don't mean to be snarky, but honest question: Did you donate? Nothing says thank you like some $$$...

It was a meta project and development ceased. For a regular project that expectation is fine, but here it does not apply IMHO.

We regularly donate to project via open collective. We frankly did not see here due to FB involvement I think.

For website hosting, it's okay but not great. We encountered issues when we tried to cache a lot of images. Their CDN storage seems really low compared to Cloudflare and Cloudfront. It results in a really bad hit ratio the moment we try to deliver a lot of images.

Can you provide more quantitative info?

It’s time saas apps realise that they can’t make 2.5x normal license money by just sticking AI to it.

In our SaaS we added it for free. We realised that there is no way to sustainably make money off of this in long term.

It’s a great feature but not 2.5x price worth feature.

We left it about a year ago due to reliability issues. We now use digitalocean apps and working like a charm. Zero downtime with DO.

You mean their App Platform right? How does the pricing compare to fly?

Yes, App Platform. Pricing is a little higher but way lower than AWS but it is fully justified. Zero downtime in the last 1 year.

With Fly, we had 3-4 downtimes in 2023 in a span of 4 months.

Ok so for hobby projects it wouldn't make sense to switch then, but glad to hear it works for you. I haven't been in a position where it would make sense - I have hobby projects where I don't care much about reliability, and then there's the infrastructure the company I work for uses and that's all on AWS

These servers are indeed job processing servers. They are critical but not milliseconds critical. Cooling, security, monitoring, backup generators, and backup of data all are taken care of.

we know but it’s actually pretty good.

aditya [at] Gumlet.com