Blog

Version 1.x of ntfy-reverse-proxy did one thing: forward webhooks to ntfy servers with routing and filtering. It worked, but every notification arrived as raw payload text. If Synology sent a JSON blob with fields scattered across text, prefix, and severity, that's what you saw in your notification.

Version 2.0.0 changes that. The worker now understands what each service is sending and transforms it into a formatted notification with a meaningful title, priority, tags, and action buttons.

When you only have one or two services sending webhooks, routing is simple — point them at your ntfy server and pick a topic. But self-hosted environments and home labs tend to accumulate services. A NAS, a firewall, a media server, a monitoring dashboard. Each one needs its own topic, and some need different ntfy servers entirely.

ntfy-reverse-proxy handles this with subdomain-based routing on a single Cloudflare Worker.

If you run self-hosted infrastructure — a company server or a home lab — and you use ntfy for notifications, you've probably pointed a few webhooks at your ntfy server directly. It works, but it doesn't scale well. Every service needs the server URL and topic hardcoded. There's no filtering, no fallback if the server goes down, and no way to route different services to different topics without giving each one a different endpoint.

We built ntfy-reverse-proxy to sit between your services and your ntfy server, handling routing, delivery, and filtering on Cloudflare Workers.