ZTLayer Logo
Start Building

Production Readiness Checklist

Before deploying ZTLayer to a high-traffic or mission-critical production environment, it is imperative to complete the following checklist. This guide ensures maximum security, guarantees high availability, and prevents accidental denial of service to your legitimate users.

1. Environment Variable Security

The ZTLAYER_API_KEY grants write access to your active security rules and telemetry data. Never commit this key to version control.

  • Next.js / Vercel: Use the Vercel Dashboard Environment Variables UI. Ensure the key is available to the Edge/Node runtime, but NOT prefixed with NEXT_PUBLIC_ unless specifically required for Client-Side Biometrics.
  • AWS / Docker: Inject the key securely using AWS Secrets Manager or HashiCorp Vault during the container build or runtime initialization.
# Correct - Server Side Only
ZTLAYER_API_KEY="zt_live_1234567890abcdef"
 
# INCORRECT - Will leak to the client bundle
NEXT_PUBLIC_ZTLAYER_API_KEY="zt_live_1234567890abcdef"

2. Global Rate Limiting Configuration

In development, rate limits might be disabled or set artificially high. In production, you must fine-tune these to prevent volumetric DDoS and abuse.

  • [ ] Global Traffic Limit: Configure a reasonable maximum for standard traffic (e.g., 1000 req/minute per IP).
  • [ ] Authentication Endpoints: Enforce aggressive, strict limits on sensitive routes like /api/auth/login, /api/auth/register, and /password-reset (e.g., 5 req/minute per IP) to proactively halt credential stuffing and brute-force attacks.

See the Rate Limits Architecture Guide for configuring dynamic limits based on user roles.

3. High Availability and Failure Modes

Enterprise systems must degrade gracefully. By default, ZTLayer is configured to Fail Open.

  • [ ] Evaluate failMode:
    • Fail Open (Recommended for E-commerce & SaaS): If the ZTLayer edge network becomes unreachable due to a catastrophic internet routing issue, the middleware will instantly bypass the check and allow the request through. This prioritizes application uptime.
    • Fail Closed (Recommended for FinTech & Healthcare): The middleware will strictly block the request and return a 503 Service Unavailable if the security check cannot be cryptographically verified. This prioritizes data security over uptime.
// Example Next.js configuration
const security = new ZTLayer({
  apiKey: process.env.ZTLAYER_API_KEY,
  failMode: 'open', // or 'closed'
  timeoutMs: 800 // Maximum milliseconds to wait for a security verdict
});

4. IP Whitelisting and Bypasses

Ensure that your internal infrastructure is not accidentally blocked.

  • [ ] CI/CD Pipelines: Whitelist the static IPs of your deployment pipelines (e.g., GitHub Actions, GitLab CI) if they perform automated end-to-end (E2E) testing against production.
  • [ ] Monitoring Tools: Whitelist uptime monitors (e.g., Datadog, Pingdom, Checkly) to ensure they do not trigger behavioral bot protections.
  • [ ] Corporate VPN: If your team uses a dedicated corporate VPN, whitelist its ASN or static IP blocks in the ZTLayer Dashboard.

5. Alerts & Monitoring Integrations

Do not rely solely on checking the ZTLayer Dashboard manually.

  • [ ] Webhook Integration: Configure a webhook in the dashboard to push anomaly events directly to your SIEM (e.g., Splunk, Datadog) or an AWS Lambda function for automated incident response.
  • [ ] Slack/Teams Alerts: Set up real-time notifications for critical spikes in blocked traffic (indicating an active attack).
  • [ ] Billing Alerts: If you are on a metered Enterprise plan, configure usage alerts to prevent unexpected overages during massive volumetric attacks.

Troubleshooting Production Rollouts

If you deploy to production and immediately see high volumes of blocked requests (False Positives):

  1. Toggle Shadow Mode: Switch your ZTLayer configuration to enforce: false. The system will continue to evaluate and log threats, but will not actively block any requests.
  2. Review the Logs: Analyze the Dashboard Analytics to identify the false positive pattern (e.g., a specific internal microservice missing a User-Agent).
  3. Adjust Rules: Create a specific bypass rule for that traffic signature.
  4. Re-enable: Switch back to enforce: true.

Next Steps