Lakera RedSDK

Deployment

How to deploy the SDK in a production or regulated environment.

Network requirements

RequirementValue
DirectionOutbound only
ProtocolHTTPS (TLS 1.2+)
Destinationred-webhooks.lakera.ai
Port443
Inbound exposureNone

If your network restricts outbound destinations, allow red-webhooks.lakera.ai on port 443 in your egress allowlist (firewall, proxy, or security group). If your policy requires IP-based rules instead, the endpoint is hosted on Convex — see the Convex networking documentation for the current ranges.

red-webhooks.lakera.ai is the only outbound destination required by the SDK itself. Your handler may also call your own agent endpoint — that traffic stays inside your network and does not need to traverse your egress controls.

Running behind a corporate proxy

If your network forces outbound traffic through a corporate egress proxy, set the usual proxy environment variables before the SDK process starts. The SDK uses Node.js’s standard fetch:

$export HTTPS_PROXY=http://proxy.internal.corp:8080
$export NO_PROXY=localhost,127.0.0.1,.internal.corp

NO_PROXY should include any local hostnames your agent lives on so that the in-network call from your handler to your agent skips the proxy.

TLS interception

If your proxy performs TLS interception (a “break-and-inspect” proxy that re-signs traffic with a corporate CA), the SDK’s outbound calls to red-webhooks.lakera.ai need to trust that CA. Point Node at your CA bundle:

$export NODE_EXTRA_CA_CERTS=/etc/ssl/certs/corp-root-ca.pem

If certificate validation fails you’ll see errors like UNABLE_TO_VERIFY_LEAF_SIGNATURE or SELF_SIGNED_CERT_IN_CHAIN in the SDK’s logs. That almost always means NODE_EXTRA_CA_CERTS is missing or points at the wrong bundle.

Runtime

The SDK is a single Node process — no listening sockets, no persistent state, no required sidecars. It is I/O-bound with a minimal memory footprint. Pass your API key via the LAKERA_RED_API_KEY environment variable; the SDK does not write the key to disk or log it.

RequirementValue
Node.js22 or later
OSAny platform Node 22 supports (Linux, macOS, Windows)
FootprintSingle Node process. No persistent state, no listening sockets.
Concurrency modelOne process per scan run is sufficient

Container deployments

No special setup is required beyond a Node 22 base image. If your image needs to trust a corporate CA (for TLS interception or air-gapped mirrors), set NODE_EXTRA_CA_CERTS in the container environment.

How the SDK connects

The SDK uses a poll-based model. A process running inside your network opens an outbound HTTPS connection to red-webhooks.lakera.ai, pulls attack prompts over it, forwards each prompt to your agent via a local call, and returns the agent’s response on the same connection.

Your network               │   Lakera
                           │
┌─────────────────┐        │
│  Your agent     │        │
└────────▲────────┘        │
         │ local call      │
┌────────▼────────┐        │   outbound HTTPS    ┌────────────────┐
│  Red SDK        ├────────┼────────────────────►│  red-webhooks  │
│  (your host)    │◄───────┼─────────────────────┤  .lakera.ai    │
└─────────────────┘        │   (same session)    └────────────────┘
                           │
                  network boundary
  • No inbound connections. Nothing listens on a port. Nothing accepts traffic initiated by Lakera. Your firewall rules only need to permit outbound HTTPS to a single hostname.
  • Your agent URL stays internal. The SDK calls your agent from inside your handler, using whatever URL or in-process call you wire up. That URL is never sent to Lakera and never crosses the network boundary.

Only the attack prompts coming from Red and your agent’s responses going back to Red transit the boundary.

Next steps