Where do developers' sensors run, and what does Loopy hand them?
A sensor turns something from the outside world — a webhook call, a timer tick —
into a Loopy event. The question: does Loopy give the developer a server to run,
or an SDK to drop into whatever they already run?
Status: webhook ingress has shipped. Both triggers — polling and
webhooks — are supported today. What landed is Option A below (the turnkey
server): loopy run hosts each @sensor(webhook=...) as an HTTP route,
fans one URL out to every sensor on it, and verifies signed ingress at the edge (GitHub's
X-Hub-Signature-256 HMAC when GITHUB_WEBHOOK_SECRET is set) — the per-source
authentication this note had filed as deferred. The server-vs-SDK comparison below is retained as
design rationale; the polyglot SDK path (Option B) remains future work.
The two options
A. Loopy gives you a server turnkey
You write sensors; Loopy runs a web server that hosts them. You run loopy run.
Nothing to wire up — it just works.
to support another language, Loopy must build & maintain a whole separate server for it.
B. Loopy gives you an SDK recommended
You host the webhook in what you already run (Next.js, Express, a Lambda…). The SDK validates the sensor's output and sends it to Loopy.
Fits where developers already work.
Cheap to support many languages — an SDK is tiny vs. a server.
you wire it into your own app (a few lines).
The key insight
These aren't opposites. The SDK is the basic building block. The server is just one
convenient thing built on top of it.
Ready-made server— optional convenience
▲ is built using ▲
SDK — author sensors · validate the event · deliver it
Recommendation: Lead with the SDK. Ship the ready-made server only as an
optional convenience (Python today). For TypeScript, start with just the SDK —
JavaScript developers already have an app to host webhooks in, and won't want to run a
separate Loopy server.
The flow is the same either way
Your sensor
webhook / poll
→
Loopy SDK
validate + deliver
→
Event Receiver
accepts events
→
Executor
runs workflows
your code · your language · your host
Loopy core — one Python implementation
Why this is the simplest path to "polyglot"
You ship one small SDK per language (easy) instead of one whole server per language (hard).
The durable executor stays a single Python implementation. Only the thin sensor edge is per-language.
A TypeScript developer just imports the SDK into their existing app — no new service to deploy.
Two things it requires
Loopy's Event Receiver becomes a small authenticated endpoint that re-checks every event (don't trust the sender).
The compiled manifest declares which sensors exist; the SDK (in your app) fulfills them.