Every plugin, and what each one is actually for
This list is mirrored from the catalog index, so it says what every plugin is. That turned out to be the wrong half of the problem. People who already run Inflowenger told us they didn't know a plugin had been added, and when they did read the entry they couldn't picture the node on a canvas.
So each one here also carries a worked scenario: what starts the flow, which nodes it runs through, and what you got at the end. The CLAUDE AGENT node is the clearest case — read as a chatbot it looks out of place in a workflow, and the jobs it is good at are reviewing an nginx config before it ships, explaining config drift, and patching a file while a person keeps the decision.
- Plugins
- 18
- Actions
- 126
- SDKs
- Go · Python · Node
- Protocol
- inflowv1
A plugin is a process you start, not a package you install
This is the part that makes the rest of the page make sense. A plugin here is a long-running process that you run wherever the thing it talks to lives, and it joins the graph over one wire protocol. Nothing gets installed into the engine.
A branch SQL Server with no inbound port still works — you start a plugin process next to it. The engine reaches the plugin, not the database.
Each node reaches one resource under the credential declared on it, so drawing the flow is composing the access.
A job can end, report its state, and be picked up days later. That's why a human approval is a step rather than a notification sent afterwards.
Go, Python and Node SDKs, or anything that speaks inflowv1. Most of this list is a few hundred lines plus a settings form.
If a plugin looks pointless, it's usually this list
The plugins where the catalog description is accurate and still leaves people with the wrong picture. The non-obvious use is the one worth knowing.
Most people read this as a chatbot node and can't picture it on a canvas. It isn't one. It's a competent operator with shell access, a working tree and a memory of what it did last time, parked inside a flow that holds the authority. The useful jobs are the unglamorous ones: read this config and tell me what it would break, patch this file, work out why the build is failing.
The scenario →The folder-of-weekly-spreadsheets problem, solved without a database. A glob like s3://bucket/logs/2026-*.csv is one table you can GROUP BY, and there is no server to run — DuckDB is linked into the plugin.
It is the escape hatch for the vendor with no API. A recorded session — sign in, filter, export — becomes one node, and that system is now addressable from a flow like anything else.
The scenario →Hybrid search is the real reason to pick it. A vector ranking and a full-text ranking from one query text, fused by RRF — which matters because exact terms (an error code, a part number) are exactly what pure vector search is worst at.
The scenario →The catalog, grouped by what it connects to
18 of 18
AI and agents
4Claude Agent
activeThe task is "do this, here, on this machine" rather than "answer this" — and you want the work to stop and ask when it hits a decision nobody delegated.
Codex Agent
betaSame shape as Claude Agent, over Codex — reach for it when you want the workspace fence enforced by the operating system rather than by the model behaving well.
Qdrant
activeA vector store several services share, with filtering that narrows the search rather than the results.
zvec
betaVector search where the deployment should carry as little as possible — no service, no port, no credential. A collection is a directory.
Databases and stores
6ClickHouse
activeMany rows, asked questions repeatedly — events, logs, metrics, anything you'll want a GROUP BY over.
DuckDB
activeThe data is files — CSV, Parquet, JSON, Excel — on disk, over https, or in a bucket. SQL over them in place.
Microsoft SQL Server
activeSQL Server or Azure SQL — including the branch instance that legally cannot leave the building.
MongoDB
activeDocuments whose shape you don't want to declare up front.
MySQL
activeMySQL or MariaDB — the same four actions as the Postgres plugin, with ? binding.
Postgres
activeThe flow's own system of record — state that outlives any single run.
Issue tracking
1DevOps and infrastructure
3GitHub (OpenConnector)
betaRead-only GitHub — repositories, activity, and the security surface — without the plugin holding a token.
Nuclei
betaTemplate-based vulnerability scanning inside a flow, with templates chosen by filter rather than one at a time.
Scrapli
betaNetwork devices over SSH or Telnet — Cisco, Arista, Juniper — with optional TextFSM parsing.
Communication
2Gmail (OpenConnector)
activeMail a flow sends or reads, as an account connected centrally rather than a token in a config file.
Telegram (OpenConnector)
activeA flow that needs to reach a person in seconds, on the thing in their pocket.
Files and storage
1Protocols and browsers
1The catalog is the list; this page follows it
A new plugin is a pull request to the catalog: an entry in plugins/index.json and a Markdown page beside it. This page is regenerated from that index by pnpm run sync-plugins, so nothing here has to be edited twice. Scenarios are written on this side, because they're about how the thing gets used rather than what it is.
Mirrored from Inflowenger/plugin-catalog at 207dd65, synced 2026-11-10.