corsproxy.dev
Comparison
You don't have a CORS problem — you have an "I need to ship an integration this week" problem. Here's how the four common answers actually stack up once production gets involved.
| Public CORS proxy cors-anywhere, allorigins |
DIY Cloudflare Worker your own ~50 LOC |
Your own backend Express/Fastify/Lambda |
corsproxy.dev managed relay |
|
|---|---|---|---|---|
| Time to first request | ~1 minute | ~30 minutes | Hours to days | ~2 minutes |
| Stable for production | No (demo-grade) | Yes, you maintain it | Yes | Yes |
| API keys per project | No | Build it yourself | Build it yourself | Yes |
| Per-key rate limits | No | Build it yourself | Build it yourself | Yes (atomic, DO-backed) |
| Request logs / usage dashboard | No | Wire up Logpush | Build it yourself | Yes |
| SSRF / private-network protection | Varies | Easy to forget | If you remembered | RFC 1918 blocked |
| Abuse handling | It's your problem | It's your problem | It's your problem | Bot detection + blocklist |
| Self-host option | Some are OSS | By definition | By definition | Same MIT runtime |
| Ongoing maintenance | None (and that's the problem) | You + Cloudflare changes | Patching, scaling, paging | None |
| Cost at low volume | Free | ~Free on CF | Hosting + your time | Free tier |
Fine for a demo or a hackathon, dangerous for a product. They rate-limit aggressively, can disappear without notice, and your users' traffic transits a server you don't operate. cors-anywhere.herokuapp.com is now limited to roughly 50 requests/hour, by design.
When to use: a one-off prototype where the cost of breakage is zero.
A 50-line Worker that adds CORS headers is the right call for one project at one company. The cost shows up later: when you need API keys, per-project quotas, abuse handling, observability, and a way to revoke access without a redeploy. Each one of those is a couple of days of work. Compounded across a team, it's the proxy infra you didn't want to own.
When to use: a single internal tool, never expected to grow.
If you already have a backend service and the third-party call is part of a server-side workflow, just put it there. You get full control, full auth, no relay layer. The trap is using "we need a backend anyway" as the reason to spin up a service whose only job is to forward requests — that's where teams burn weeks reinventing a relay.
When to use: the backend already exists, or the integration needs server-side state (secrets, queues, retries).
A managed relay aimed at the case the other three options handle badly: a frontend team shipping production browser integrations who doesn't want to own proxy infrastructure. You get per-key quotas, request logs, a dashboard, abuse controls, and SSRF protection on day one. If you later need full control, the same runtime is MIT-licensed on GitHub — start hosted, move to self-hosted, same wire protocol.
100 requests/day on the free tier. No credit card. Self-host the same runtime any time.
Start free Read the docs