Bot detection for your Render services.
Add WebDecoy’s middleware to an Express, Next.js, Fastify or Hono app on Render, or deploy a starter with one button. It sees the crawlers that never run JavaScript and records an address a visitor cannot forge.
Set up WebDecoy on Render
Start from a template or your app
Deploy one of five WebDecoy starters with its Deploy to Render button (Express, Next.js, Fastify, Hono, Angular SSR), or install the WebDecoy package for your framework in an existing app.
Use the header a visitor cannot forge
Pass trustProxy: 'cloudflare' to the middleware. Render keeps whatever X-Forwarded-For the client sent, so its first entry is the visitor’s choice. Cloudflare, which Render serves through, sets CF-Connecting-IP and rejects a request that supplies its own.
Add your API key
Create an API key in WebDecoy and paste it into WEBDECOY_API_KEY when Render asks, or set it in the service’s Environment. Keep it out of your repository.
Verify, then decide on enforcement
Request any page with the user agent WebDecoy-Test/1.0 and confirm the labeled test detection. The middleware starts in Monitor; switch it to Enforce when you trust what it flags.
See the requests a browser tag misses
AI crawlers and HTTP tools fetch pages without running JavaScript. Middleware sees every request that reaches your service, reports the automated ones, and plants a hidden link that only bots follow.
In Monitor it records what it would block and serves every request. In Enforce it answers blocked requests with a 403 inside your app. There is no edge validator on Render; the policy runs in your code.
Why trust proxy: true is the wrong setting
A common recommendation for Render is to trust every proxy and take the first X-Forwarded-For value. Render appends to what the client sent, so that value is whatever a visitor wrote, and every per-IP rule inherits the forgery.
The starters read CF-Connecting-IP for WebDecoy, and the Express-based ones trust exactly three hops for the app’s own address. Both were checked against a live Render service with a forged header.
Questions about Render
Does the Deploy to Render button cost anything?
The starters deploy on Render’s free instance type. Free services sleep when idle, so the first request after a pause can take up to a minute.
Does it block bots?
Not by default. The middleware starts in Monitor and serves every request. Enforce returns a 403 for blocked requests, and you choose when to switch.
Do the starters also work on Railway?
Yes. The same repositories deploy to Railway and pick the right client-IP setting from the platform they run on.
Choose your platform
Start with the setup that matches where your site runs. Monitoring, request verification, and provider firewall actions are separate choices.
| Platform and setup guide | Detection | Protection |
|---|---|---|
| Netlify | Extension injects a crawler sensor at build time. | Opt-in clearance checks on protected paths; Monitor first, then Enforce. |
| Cloudflare | Managed Worker observes requests before your origin. | Worker clearance validation and separately configured WAF response actions. |
| Vercel | Log drain on Pro or Enterprise; Next.js SDK alternative. | Configure Firewall actions or SDK policy separately from the monitoring install. |
| AWS CloudFront | Browser script or SDK for detection. | Lambda@Edge clearance validator; optional AWS WAF integration. |
| WordPress | Plugin adds browser detection and decoy surfaces. | WordPress rules and form protection; an edge validator extends coverage before PHP. |
| Railway | SDK middleware for Express, Next.js, Fastify or Hono; one-click starters. | SDK policy in your app: Monitor first, then Enforce returns a 403. |
| Render | SDK middleware for Express, Next.js, Fastify or Hono; one-click starters. | SDK policy in your app: Monitor first, then Enforce returns a 403. |
| Shopify | App embed and Web Pixel cover storefront and checkout activity. | Order tagging and risk assessments support merchant decisions; no edge validator installed by the app. |