Production readiness verifier for n8n workflows.

Paste or upload an exported n8n workflow JSON. Drygate runs static analysis and sandbox execution, scores the workflow 0–100, and generates a prioritized remediation plan - before it breaks in production.

Built for LovHack Season 2 · March 2026

n8n workflows that pass every editor test regularly fail in production. Hardcoded credentials, missing error branches, credential references with no attached credential, no global error workflow - none of these surface in the n8n editor. Drygate catches them automatically.

Pipeline (four stages, runs in ~30–60s):

Parse → Static Analysis → Sandbox Execution → Remediation Plan

1. Parse - validates JSON shape, nodes array, connection graph, trigger presence
2. Static gate - graph and credential rules, expression analysis ({{ }}), rate limiting (loops vs APIs), webhook security (auth, response mode, path guessability), input validation (trigger → destructive paths), AI / LangChain checks (system prompt, memory, errors), AI prompt-injection heuristics for untrusted input in LLM parameters, production manifest and egress guardrails, plus workflow complexity (informational score: nodes, branches, depth, sub-workflows). Issues are grouped on the report into Security, Reliability, Logic, Configuration, and AI / Agents.
3. Sandbox - imports the workflow into an isolated n8n instance, coerces graph entry triggers (webhook/schedule/…) to a single manual run, executes, captures per-node traces and runtime errors. Sticky notes are excluded from coverage and traces. Trigger nodes are classified separately from credential-blocked nodes and appear under Trigger in the coverage breakdown, not under Blocked. Execution payloads are normalized for multiple n8n API shapes, with a short re-fetch after completion so runData is populated when the first response is still sparse.
4. Remediation - deterministic fix cards (step-by-step, effort estimates). If GROQ_API_KEY is set, up to five high/critical issues also get an optional AI suggestion block (Groq openai/gpt-oss-120b by default) alongside deterministic steps, and the full plan can be AI-enhanced; failures there never block the pipeline.

Outputs:

• Readiness score (0–100) with a named band
• Complexity badge (low → very high) on the shareable report
• Per-issue list with severity, category, node reference, and code; expandable remediation + optional AI hint
• Workflow graph and simulation coverage breakdown (executed / blocked / skipped / trigger)
• Simulation coverage % (relative to nodes the sandbox can run)
• Shareable report link (no login required)
• Full verification history

Fail-closed rule: if HARDCODED_SECRET, MISSING_TRIGGER, CIRCULAR_DEPENDENCY, or UNAUTHORIZED_EGRESS_DETECTED is found, score is capped at 40 regardless of other findings.

• Node.js 18+
• Docker Desktop running
• Git

git clone https://github.com/shaileshdev4/drygate.git
cd drygate
npm install

Copy the example env file:

cp .env.local.example .env.local

Edit .env.local - you need a PostgreSQL URL (local Postgres or Supabase). Set DIRECT_URL to a direct/session connection for prisma db push (see .env.local.example).

NEXT_PUBLIC_APP_URL=http://localhost:3000
DATABASE_URL=postgresql://...
DIRECT_URL=postgresql://...
SANDBOX_N8N_URL=http://localhost:5678

Push the database schema:

npm run db:push

docker compose up -d

This starts n8n (n8nio/n8n:latest) and the mock gateway on sandbox-net. n8n listens on localhost:5678. The app’s sandbox controller establishes a session against that instance (owner setup + login on first use). Leave the stack running.

Verify n8n is up:

curl http://localhost:5678/healthz

npm run dev

Open http://localhost:3000. Go to /verify?demo=1 or click Load demo on /verify to run the prefilled Lead Scoring & CRM Sync sample (src/data/demo-workflow.json).

Set SANDBOX_N8N_URL to the base URL of a running n8n (e.g. http://localhost:5678 or your Railway public URL). The controller imports the workflow, runs it via n8n’s REST APIs (with version fallbacks), and polls executions.

SANDBOX_N8N_URL=http://localhost:5678
SANDBOX_N8N_API_KEY=   # optional - Settings → API in n8n

Local docker-compose.yml uses n8nio/n8n:latest (aligns with typical Docker Desktop pulls). Override the ephemeral image tag with SANDBOX_N8N_IMAGE only if you add back per-request Docker mode.

If SANDBOX_N8N_URL is unset, the sandbox layer throws - per-request Docker + n8n is not wired up in the current build. Use persistent n8n only.

Use a public HTTPS URL for n8n if private networking to the app is unreliable; set SANDBOX_N8N_URL to that URL. See docs/DEPLOYMENT.md for full detail.

1. Create a project at supabase.com
2. Transaction pooler (often port 6543) → DATABASE_URL (add ?pgbouncer=true if Prisma reports prepared-statement errors)
3. Session / direct (often port 5432) → DIRECT_URL for prisma db push

1. New project → Dockerfile from repo railway-n8n.dockerfile (or equivalent), or image n8nio/n8n:latest with the same env ideas as the Dockerfile.
2. Add a volume on /home/node/.n8n so the instance owner and data survive restarts.
3. N8N_SECURE_COOKIE=false is set in railway-n8n.dockerfile so session cookies work behind Railway’s HTTP proxy.

1. Add Service → GitHub repo → select this repo
2. Copy variables from .env.production.example and set SANDBOX_N8N_URL to a URL the Next service can reach (internal hostname or public n8n URL)
3. railway.toml start command (non-fatal db push, bind PORT):

[deploy]
startCommand = "npx prisma db push --skip-generate || echo '[railway] prisma db push failed - check DATABASE_URL / DIRECT_URL env vars' ; npm run start -- -p ${PORT:-3000}"

NEXT_PUBLIC_APP_URL=https://your-app.up.railway.app

DATABASE_URL=postgresql://...pooler...:6543/postgres?pgbouncer=true
DIRECT_URL=postgresql://...session...:5432/postgres

SANDBOX_N8N_URL=https://your-n8n.up.railway.app

drygate/
├── src/
│   ├── data/
│   │   └── demo-workflow.json        # Built-in demo for /verify?demo=1 & Load demo
│   ├── app/
│   │   ├── api/
│   │   │   ├── verify/
│   │   │   │   ├── route.ts          # POST - starts pipeline
│   │   │   │   └── [id]/
│   │   │   │       ├── route.ts      # GET - terminal snapshot
│   │   │   │       └── stream/       # GET - SSE stream
│   │   │   ├── report/[shareToken]/  # Public report API
│   │   │   └── history/
│   │   │       ├── route.ts          # GET list, DELETE all (demo-user)
│   │   │       └── [id]/route.ts     # DELETE one row
│   │   ├── verify/                   # Upload + pipeline UI
│   │   ├── how-it-works/             # Product walkthrough
│   │   ├── report/[shareToken]/      # Shareable report page
│   │   ├── dashboard/                # History + delete controls (client)
│   │   ├── (marketing)/
│   │   │   └── page.tsx              # Landing (/)
│   │   └── layout.tsx                # Header + Footer
│   ├── lib/
│   │   ├── validator/                # Static analysis
│   │   │   ├── index.ts              # Orchestrator + complexity report
│   │   │   ├── classifier.ts         # Coverage: trigger vs blocked; sticky excluded
│   │   │   ├── complexity.ts         # Maintainability complexity score
│   │   │   ├── parser.ts             # Workflow graph parser
│   │   │   └── checks/               # Per-rule modules
│   │   │       ├── structure.ts
│   │   │       ├── credentials.ts
│   │   │       ├── error-handling.ts
│   │   │       ├── loops.ts
│   │   │       ├── expressions.ts
│   │   │       ├── ai.ts
│   │   │       ├── rateLimiting.ts
│   │   │       ├── webhookSecurity.ts
│   │   │       └── inputValidation.ts
│   │   ├── scorer/
│   │   │   └── index.ts              # Scoring engine + bands
│   │   ├── sandbox/
│   │   │   └── controller.ts         # n8n sandbox + node traces
│   │   ├── remediation/
│   │   │   ├── deterministic.ts      # Fix cards + optional AI-enhanced plan
│   │   │   └── categories.ts         # Issue → Security / Reliability / …
│   │   ├── ai/
│   │   │   ├── groq.ts               # Groq OpenAI-compatible client (remediation AI)
│   │   │   └── fixSuggestions.ts     # Optional per-issue AI hints
│   │   ├── guardrails/               # Egress, credential manifest, fuzz
│   │   ├── sse/
│   │   │   └── streams.ts            # SSE fan-out store
│   │   └── db/
│   │       └── index.ts              # Prisma client (+ pooler URL warning)
│   ├── components/
│   │   ├── layout/
│   │   │   ├── Header.tsx
│   │   │   └── Footer.tsx
│   │   ├── report/
│   │   │   └── ReportCategorizedIssues.tsx
│   │   └── ui/
│   │       ├── WorkflowGraph.tsx
│   │       ├── CoverageBreakdown.tsx
│   │       └── ScoreGauge.tsx
│   └── types/
│       └── index.ts                  # All shared types
├── prisma/
│   └── schema.prisma
├── mock-gateway/                     # HTTP proxy (local compose → n8n egress)
│   ├── Dockerfile
│   └── index.js
├── docker-compose.yml                # Local n8n + mock-gateway
├── railway-n8n.dockerfile            # Optional Railway n8n service
├── railway.toml                      # Railway deploy config
└── docs/
    ├── DEPLOYMENT.md
    ├── INTRO.md
    ├── PROJECT.md
    └── GUARDRAILS.md

Starts at 100 and deducts per finding.

(Expression and other codes are defined in src/lib/scorer/index.ts.)

If more than 60% of analyzed nodes are credential_blocked, destructive_blocked, or structural_only (excluding trigger nodes and sticky notes, which are not part of coverage), score takes an additional 10-point deduction (low confidence in result).

Start a verification.

Body:

{ "workflow": { "name": "...", "nodes": [...], "connections": {...} } }

Response:

{ "id": "cuid", "shareToken": "nanoid" }

SSE stream. The server emits default message events with JSON bodies shaped as { "type": "...", "payload": { ... } }. Common type values:

Terminal snapshot - final score, issues, reports.

Public report - no auth required.

History for userId === "demo-user" (matches current app). DELETE removes rows from the database; shared report URLs for deleted rows stop working.

Liveness / diagnostics (deployment debugging).

• Scoring is heuristic, not a formal proof of production safety
• Sandbox cannot validate real credentials - integration nodes are usually credential_blocked; workflow triggers are labeled trigger, not blocked, for clearer reporting
• Ephemeral Docker-per-request sandbox is disabled; use persistent n8n only
• Egress allowlist guardrails assume traffic can be observed (mock gateway path); persistent public n8n won’t see the same proxy setup
• Very new n8n exports can still surface import/API quirks - pin n8n if you need a frozen baseline

• Expression static analysis - null/array/fallback and dead $node reference checks across {{ }} parameters.
• Extended static rules - rate limiting, webhook hardening, input validation, AI agent hygiene, prompt-injection heuristics, workflow complexity metric, categorized issues on the report.
• Optional AI (Groq) - openai/gpt-oss-120b (configurable via GROQ_REMEDIATION_MODEL) for per-issue hints and plan enhancement when GROQ_API_KEY is set.
• Sandbox reliability - only entry graph triggers are coerced to manual (avoids a second webhook becoming a duplicate manual trigger); execution runData is read from multiple n8n response shapes (incl. nested data.data); after a run finishes, a delayed re-fetch reduces empty traces / 0% simulation coverage on fast polls.

The sandbox still has a coverage gap on credential-heavy workflows: most integration nodes stay credential_blocked, so simulation coverage is often low. The main lever for higher execution coverage without real secrets is pinData simulation (below).

n8n's official pinData feature lets you inject synthetic output into any node so downstream nodes receive it and execute normally. This is exactly what the n8n editor uses for testing.

For every credential-blocked node in a workflow, Drygate will generate realistic synthetic output based on the node type - Gmail returns a message object, Postgres returns rows, OpenAI returns a completion - and inject it as pinData. The full downstream chain then executes against real data flow.

Estimated coverage improvement: 8% → 70–90% on typical integration workflows. No credentials required. No Docker required. Works on Vercel.

The pinData generator needs coverage for approximately 30 node types to cover 80% of community workflows.

For workflows where even pinData cannot produce meaningful coverage (complex branching, dynamic expressions, AI agent chains), Drygate will send the full workflow JSON plus node type registry to an LLM and ask it to:

• Trace data flow through the execution graph with realistic synthetic inputs
• Identify expressions that will fail under specific payload shapes
• Predict which branches are unreachable given the trigger configuration
• Surface logic errors that neither static analysis nor execution catches

This produces findings similar to runtime traces without requiring any execution. One API call per workflow.

n8n has had five critical RCE vulnerabilities in the last four months (CVE-2025-68613, CVE-2026-27577, CVE-2026-27493, CVE-2026-27495, CVE-2026-27497) - all from unsafe expression evaluation. Over 100,000 vulnerable instances were identified on the internet.

Drygate will add a dedicated security layer:

• Scan every {{ }} expression for patterns matching known injection vectors
• Flag Code nodes using constructs that have historically enabled sandbox escapes (prototype chain access, process.mainModule, child_process)
• Flag Form trigger nodes exposed publicly (the CVE-2026-27493 attack surface)
• Check workflow metadata for n8n version references against the known CVE timeline

This turns Drygate from a quality gate into a security gate - a distinct value proposition for enterprise teams running self-hosted n8n at scale.

Per-issue AI suggestions (Groq) are already available for a subset of codes when GROQ_API_KEY is set.

MIT

Drygate - Ship n8n workflows without guessing.