How Silker works
Silker inspects traffic where your app runs and blocks threats in real time. Detection runs on your own infrastructure - we only receive sanitized security events.
Three ways to deploy the guard
Same detection engine. Where it sits depends on where your app runs.
Node.js SDK
One line in Next.js, Express or any Node backend. Silker runs inside your app and blocks threats locally, before they reach your model or database.
Cloudflare Worker
Deploy a Worker on your Cloudflare zone. Traffic is inspected at the edge before it hits your app - no changes to your codebase.
Docker proxy
Run the proxy in front of any backend - PHP, Java, Python, Go. Point your traffic at it. No Cloudflare required.
Apps with no backend (browser → Supabase)
Some AI-built apps talk to Supabase directly from the browser, with no server in between. There is no place to put an inline guard there - and blocking in the browser can be bypassed. For those apps the honest answer is different: we lock the database down (Row-Level Security) and monitor access, rather than pretend to block live. We'll always tell you which protection actually applies to your setup.
Traffic stays with you
Detection runs in your runtime or your edge. Your requests never route through our servers.
Only events leave
We receive sanitized security events (what was blocked and why) - not your users' payloads.
PII redacted first
Sensitive data is redacted before anything is logged or sent.