remove.bg's API is shutting down Dec 1 — here's what that actually means for you

Noah — Wed, 30 Sep 2026 17:22:21 +0000

If you've got anything in production calling api.remove.bg, you have a deadline now: December 1, 2026, 9:00 AM CET. That's when the standalone remove.bg site and API shut down for good.

Canva bought remove.bg back in 2021, and they've now announced they're folding it into the main Canva product. If you're a designer using remove.bg through canva.com, this is basically a non-event — the feature just moves into the editor you probably already use.

If you're a developer calling their API from code, it's a different story. The background-removal feature is going into Canva. The API is not. According to their own migration notes, api.remove.bg traffic is being redirected to Leonardo.Ai — a completely different company with its own auth, its own pricing, its own rate limits. This isn't a domain change or a version bump. It's "pick a new vendor, integrate it, test it, ship it" — with a hard date attached.

Who this actually affects

Not everyone. If you use remove.bg by hand through their website or through Canva's editor, you're fine — that flow keeps working, just inside Canva. This matters if you have code somewhere — a backend job, a Shopify app, an n8n workflow, a script that's been quietly working since 2019 — that POSTs an image to api.remove.bg/v1.0/removebg with an API key. That code stops working on December 1st. No grace period mentioned in what they've published so far.

What I'd actually do before the deadline

Not going to pretend there's one obvious answer here, because there isn't — it depends on volume, budget, and whether you want to keep depending on someone else's API at all.

Leonardo.Ai — the "official" successor for API traffic. Probably the least code change if you're already deep in the remove.bg ecosystem, but it's a different pricing model and you should read the fine print before assuming it's a drop-in.
PhotoRoom — built specifically around e-commerce product photos, has an API, has been around a while.
Self-hosted (rembg, or similar open models) — if you're processing enough volume that per-image API costs bother you anyway, this is the moment to stop renting and just run the model yourself. No shutdown risk, because there's no vendor to shut anything down.
Fottly — this is the thing I built, so take it with the appropriate grain of salt: it's a self-hosted image API (AGPL-3.0) with background removal and resizing/format conversion in the same call, plus a hosted version if you don't want to run a server. I'm not going to tell you it's the right fit for everyone reading this — if you're already happy with Leonardo or PhotoRoom, there's no reason to move twice. But if this shutdown is making you reconsider being dependent on a single vendor's roadmap at all, self-hosting the model is worth a look.

The actual lesson here

This is at least the second time in a couple of years that a widely-used image API has changed hands and reshuffled its terms on short notice (Cloudinary pulled free background removal for new accounts back in February). If your product depends on a hosted image API, it's worth asking now — not in November — what your fallback is if that vendor changes the deal again. Sometimes the answer is "switch to a different hosted API." Sometimes it's "just run the open-source model yourself and stop worrying about this."

Either way: if you have anything calling api.remove.bg, put December 1st on a calendar today.

Repo, if you want to see how the self-hosted route works end to end: https://github.com/Noah-1919/Fottly

I got tired of metered image CDN pricing, so I built my own

Noah — Thu, 20 Aug 2026 16:37:17 +0000

I've built and rebuilt image pipelines for side projects more times than I can count, and every time it's the same story: hosted CDN, love it for a month, then start dreading the bill because it moves with traffic you don't control. So this time I just self-hosted it. Fottly — image transforms and AI background removal through a plain URL, AGPL-3.0, reading from a bucket I actually own.

GET /t/w_800,c_fit,bg_remove,f_webp/product.jpg

Two things from building it that are worth sharing.

Picking the background removal model took way longer than it should have. The default one cropped a leg off a photo of a character standing up. Switched models, that fixed it, but then a "better" model OOM-killed the container because its file was almost 1GB. Ended up resizing images to 1600px before background removal even runs — barely hurts quality, stops the crashes.

The one that actually annoyed me: I had ufw locked down, default deny, only ssh/http/https open. Turns out Docker writes its own iptables rules when you publish a container port, and those rules run ahead of ufw's — so the "firewall" wasn't blocking anything for stuff running in containers. Fixed it by binding to 127.0.0.1 and putting Caddy in front. If you run ufw + Docker, worth checking you're not in the same boat.

Repo's here if you want to poke at it: https://github.com/Noah-1919/Fottly

DEV Community: Noah

remove.bg's API is shutting down Dec 1 — here's what that actually means for you

Who this actually affects

What I'd actually do before the deadline

The actual lesson here

I got tired of metered image CDN pricing, so I built my own