# Nexus Hook > A webhook batching proxy that sits between Sanity CMS and Vercel deployments. Collects rapid-fire content updates and triggers a single Vercel build after a configurable quiet period — saving build minutes, reducing costs, and preventing deployment spam from collaborative editing sessions. - URL: https://renato-dulog.is-a.dev/works/nexus-hook - Author: Renato Dulog - Category: tool - Tech stack: Next JS, Supabase, Tailwind CSS, Typescript - Updated: 2026-07-21 ### What I Built A webhook batching proxy that sits between Sanity CMS and Vercel. Instead of every content save triggering its own deployment, Nexus Hook queues incoming webhooks and waits for a configurable period of silence before firing a single build. The core mechanic: every new webhook resets the timer to full duration, so a build only triggers after editors have genuinely stopped making changes. ### Why I Built It Working with Sanity and Vercel, every content change fires a webhook and kicks off a fresh deployment. In collaborative editing sessions — or when an editor makes a dozen tweaks in quick succession — that means a dozen builds, a dozen deployment minutes burned, and a queue of redundant deployments that all produce the same end result. The fix seemed obvious: batch the webhooks, wait for silence, send one. The hard part was building it in a way that's configurable, multi-user, and actually reliable under real editing patterns. ### What Made Me Start The insight that made this click was the timer reset logic. A naive approach would batch changes over a fixed window — "collect for 5 minutes, then send." But that means a build fires mid-edit if the editor started 5 minutes ago. The right behavior is: start a timer on the first change, reset it on every subsequent change, and only trigger when the timer runs out with no interruptions. That single design decision — reset on arrival, not count from start — is what makes the tool actually useful in real editing sessions instead of just theoretically useful. ### How I Did It #### The Queue and Cron System Incoming webhooks from Sanity hit a public proxy endpoint and get written to a Supabase PostgreSQL queue. A Vercel Cron job runs every 2 minutes, checks all active webhook configs, and for each one calculates the time since the most recent queued item. If that gap exceeds the configured wait time, it fires the target Vercel webhook and deletes the queue entries immediately — no logs kept by design. #### Auth and Multi-User Isolation Supabase Auth handles login, and Row Level Security policies ensure users can only ever see and manage their own webhook configs and queue items. The cron processor runs across all users' configs simultaneously, but each user's data is fully isolated from every other. #### Real-Time Dashboard The dashboard polls the status endpoint every 5 seconds and uses a client-side interval to count down the timer in real time — showing exactly how many changes are queued and how long until the build triggers. A manual "Trigger Now" button lets users bypass the timer and force an immediate build when needed. ### What Makes It Unique #### Privacy-First: No Logs Queue items are deleted immediately after processing. No activity history, no logs, no stored webhook payloads persisted beyond what's needed to trigger the build. This is a deliberate architectural choice, not an omission — Sanity content is sensitive, and a proxy service shouldn't be accumulating a record of editorial activity. #### Configurable Per Webhook Wait time is configurable per webhook, not globally. A high-traffic news site might want a 1-minute window; a slower marketing site might prefer 10. Each webhook config is independent, and editors can adjust it from the dashboard without touching any code or environment variables. ### Why This Matters to Me Nexus Hook was the first project where I owned the entire backend layer — database schema, RLS policies, cron scheduling, API auth middleware, and a real-time UI on top of it. It demonstrated that I can think through systems problems, not just UI problems. - **Real problem**: Solved an actual pain point from my own Sanity + Vercel workflow - **Backend ownership**: Auth, RLS, cron jobs, queue processing — all designed and implemented end-to-end - **Multi-user from day one**: Isolation and RLS baked into the schema, not bolted on later - **Thoughtful defaults**: Privacy-first architecture, no unnecessary data retention ### The Bigger Picture Good developer tooling is invisible when it works. Nexus Hook is the kind of thing you set up once, forget about, and only notice when it saves you from a cascade of unnecessary deploys. That invisibility — reliably doing one thing correctly without demanding attention — is the goal. It also opened a pattern: build the tools your stack is missing rather than waiting for someone else to build them. ### Key Takeaway The best developer tools solve exactly one problem and solve it completely. Nexus Hook doesn't try to be a deployment platform or a webhook manager — it's a batching proxy, and it does that one thing reliably. Scope clarity is what makes small tools actually get built and actually get used.