Hey folks,
If you’re self-hosting n8n and also using Claude Code (or Cursor, or Codex, or any other cloud-side AI agent) for actual work, you’ve probably hit this: your n8n lives on localhost or some private VLAN, your agent lives in someone else’s cloud, and there’s no sane way for the agent to trigger your webhooks or call your local APIs. So you end up port-forwarding a dev box, or cobbling together a tunnel, or giving up and pasting curl snippets.
I’m on the team building NyxID, which is our attempt to stop doing that. It’s an open-source gateway (Apache 2.0) that sits between your agent and whatever you want the agent to reach. Self-hostable via docker-compose; early hosted version also exists.
The piece most relevant to n8n setups is the credential-node bit. You run a small node on the same network as your n8n instance; the node opens an outbound WebSocket to the gateway. When your agent calls through the gateway, the request comes back down that tunnel and hits your localhost instance directly. No inbound port, no VPN, no public DNS for your n8n.
Credentials live on the gateway side, not in the agent. Your agent gets a single NyxID key; everything downstream — the n8n basic auth, a third-party API key, an OAuth bearer — gets injected at proxy time. The agent never sees a raw secret.
The other piece worth mentioning — turning REST APIs into MCP tools — works for n8n too, if you can get an OpenAPI spec out of your workflow. Feed the spec to NyxID and the endpoints show up as tools an MCP client can call.
Same gateway, same credentials. Not doing a step-by-step setup here; that’s going into a separate Tips & Tricks post. This one is more of a “does this even map to what you need” check.
If you’re running self-hosted n8n alongside cloud AI agents right now, what do you use? Anyone already turning n8n webhooks into MCP tools some other way? What broke?
Repo: GitHub - ChronoAIProject/NyxID: Connect AI agents to any API, anywhere. Securely. Open-source gateway that proxies requests, injects credentials automatically, punches through NAT to reach localhost services, and wraps REST APIs as MCP tools. Per-agent isolation. Never expose a raw key. · GitHub
Using web-search and searxng as MCP server
hey, appreciate the questions — sounds like you’ve been in the same trenches.
On credentials: NyxID doesn’t touch n8n’s encrypted secrets store at all. It operates purely at the HTTP layer — users store credentials in NyxID separately, and NyxID injects them into outgoing requests as a header, query param, or body field, whichever the downstream expects. For self-hosted setups the credential never leaves your machine: NyxID’s local node agent handles injection (AES-256-GCM local file or OS keychain), and the server only routes over WebSocket. So NyxID sits alongside n8n’s credential system, not inside it.
On schema mapping: honest answer — depends on what you’re wrapping.
If the service has an OpenAPI / Swagger spec, we auto-discover it (probes /openapi.json, /swagger.json) and generate typed MCP tool definitions with no manual work. That covers n8n’s management REST API.
For arbitrary webhooks (like user-defined n8n workflows), it’s not zero-config today — they get exposed as a generic {method, path, body} MCP tool, which works but has no typed input/output contract.
Our fix for this is Ornn — our skill platform, available today as a service on hosted NyxID. You describe what an n8n workflow does in natural language and ornn__generateskill produces a typed skill (prompt + scripts + schema) that your agent can discover and execute through the same MCP server. So the practical path for an n8n webhook is: register the endpoint in NyxID for credential injection → generate a skill in Ornn for the typed schema → agent calls it via MCP. Not as clean as “paste a webhook URL and it just works,” but also not “hand-write every schema.”
Curious what’s been working on your end — if you’ve got a pattern for n8n webhook schemas that holds up in production, would genuinely like to compare notes.