You Extend Flomorphic the Way You Install a Browser Extension

Ask most software platforms to do something they don't do yet and the answer is a chore. Fork the repository. Learn its internals well enough not to break them. Add your code where it fits. Open a pull request, wait for it to land, and redeploy the whole thing. "Extend it" quietly means "become a maintainer of it" — and that price is why so many good integrations never get built. The capability was easy; the ceremony around it wasn't.

Flomorphic doesn't work that way, and the reason is worth stating plainly at the top, because it changes what "extend" even means: you add a new capability the way you add an extension to your browser. You don't touch the platform's source. You don't rebuild it. You open a menu, add a plugin, and a new node appears in the palette — ready to drop into a flow like every node that shipped with the product. No fork. No PR. No redeploy of anything you didn't write.

That single fact is the subject of this piece. The mechanics of writing plugin code live elsewhere; what this is about is the shape of the thing — that plugins are how Flomorphic reaches any resource you already run, that installing one is a menu click rather than a merge, and that on the rare day the resource you need isn't in the catalog yet, authoring the plugin for it is close to free. Connect to anything. Install what exists. Build what doesn't, easily. That's the whole surface.

Two seams, and only one of them is a menu

There are two sanctioned ways to make an Inflowenger-based system do something new, and they sit at different depths.

Extrinsics are the backend seam. An extrinsic is a service that lives between the Inflowenger runtime and your business logic — the middle layer where the runtime hands off to code that knows your domain. It's the right tool when the thing you're adding belongs behind the platform: a service boundary, a place to keep logic that the runtime calls into but that isn't itself a node on anyone's canvas. Extrinsics are powerful, but they're infrastructure. They don't show up in a palette, and a person composing a flow never sees one directly.

Plugins are the front seam — the one that becomes a node. A plugin has its own protocol and its own SDK, and it exists precisely so that a capability can appear in the palette and be composed like any built-in node, with its own configuration form and its own place on the diagram. This is the seam that behaves like a browser extension: self-contained, installed through a menu, visible the moment it's added, removable just as easily.

The rest of this article is about the plugin seam, for one reason: it's the full-featured, install-and-go path, and it's the one that turns a single platform into an ecosystem. If extrinsics are how you wire the platform into your backend, plugins are how a capability becomes something anyone on the runtime can install.

The install experience is the point

Picture how a browser extension works. You don't clone Chromium. You open a menu, pick the extension, and it's there — a new button in the toolbar, a new capability in every tab. The browser didn't change; your copy of it grew a feature. Uninstall it and the browser is exactly what it was.

A Flomorphic plugin installs the same way. There's a menu for adding plugins, and adding one registers a new node type into the palette. From that moment the node is a first-class citizen: you drag it onto the canvas, it opens a real configuration dialog, it participates in the flow, it streams its progress onto the diagram like everything else. Nobody edited the runtime. Nobody redeployed the product. Your instance simply knows one more kind of node than it did a minute ago.

This is why forking never enters the conversation. Forking is what you do when the only way in is through the source. A plugin has a protocol — a stable contract the runtime already speaks — so the plugin and the platform meet at that contract and nowhere else. The plugin evolves on its own cadence, versioned independently, deployed wherever its author wants it to run. The platform evolves on its own. Neither is a branch of the other. That decoupling is exactly what makes the install feel weightless: there's nothing to keep in sync because there's no shared codebase to drift.

Write it once, and it runs wherever the runtime does

Here's the part that makes "install like an extension" bigger than a convenience.

A plugin isn't written against Flomorphic. It's written against the Inflowenger runtime's protocol — the same protocol every product built on that runtime speaks. Flomorphic is one such product. There can be others, tailored to different industries, audiences, or deployments. A plugin written once for the protocol loads into all of them, unchanged.

So the browser analogy sharpens: it's less like an extension for one browser and more like an extension that works in every browser built on the same engine, automatically, because it targets the engine rather than any one browser's chrome. Portability isn't something the plugin author negotiates per product. It's a property of the runtime. Write the capability once, and it's installable anywhere the runtime runs — a colleague's Flomorphic, a customer's on-prem deployment, an entirely different Inflowenger-based product you've never seen.

That's also what lets these systems slot into almost any environment. The runtime carries the same protocol whether it's running in a cloud tenant, on a laptop, or air-gapped inside a company's own walls — and a plugin, being just a program that speaks that protocol and runs where you deploy it, comes along for the ride. You aren't shipping a plugin to a platform. You're shipping a capability to the runtime, and the runtime is already wherever you need it to be.

Plugins bring a connection to anything you already run

The reason plugins matter isn't the install animation. It's what a plugin is: a seamless connection between a flow and a resource that already exists in your world. A database, a message queue, an internal API, a piece of hardware, a SaaS your company lives in — if it has a way to be talked to, a plugin turns it into a node your flows can use as naturally as any built-in one. Extending Flomorphic, in practice, almost always means connecting it to something you already own.

Databases are the cleanest example. Say a company has a store the platform has never heard of — its own vector database, or a document store like MongoDB, or a Postgres instance holding the records the business actually runs on. They want their flows to read and write that store as naturally as any built-in node reads a file or calls a model.

They don't file a feature request and wait. They don't fork Flomorphic to teach it about their database. They write a plugin.

And here's the detail that matters most for the "no internals required" claim: the plugin brings its own configuration UI, so its author never touches the platform's frontend. A plugin node declares the settings it needs — the connection string, the collection name, the index, the credentials profile — as a form, and the runtime renders that form on the canvas. The operator who later drops the node into a flow gets a proper dialog with typed fields and validation, and the plugin author wrote no frontend to produce it. They never worried about how node settings look on the front side, because that isn't their job — it's the runtime's. They described what the node needs; the platform handled how it's asked for.

The result is that a company's private vector store, or its Mongo, or its Postgres, becomes a native palette node — configured visually, governed like every other node, and usable in any flow. The team that knows the database best built the integration, without knowing a thing about Flomorphic's internals, and without a single change to the platform they installed it into. That's the same instinct behind giving a company its own brain: the infrastructure that holds your organization's knowledge should be a first-class participant in your flows, not a thing you bolt on from outside.

Not in the catalog? Building the missing one is the easy part

The catalog will never cover everything on the day you need it — and that's fine, because it doesn't have to. The guarantee that actually matters isn't "every resource is pre-built." It's "the missing one is cheap to build."

Say you run ClickHouse and there's no ClickHouse plugin listed yet. On most platforms that sentence ends a project. Here it starts a short one. The SDK repo ships two things that turn plugin authoring from a protocol-learning exercise into a fill-in-the-blanks task: a cookbook — worked, copyable recipes for the shapes a plugin actually needs — and a SKILL.md, an agent skill that teaches a coding agent the SDK's real API, its rules, and its known gotchas. Point a coding agent like Claude Code at that skill, hand it the cookbook and your resource's client library, and you get a correct, working plugin back — connect, query, write, the settings form, all of it — without memorizing a wire protocol or reading the runtime's source. The skill and cookbook are the knowledge you'd otherwise have to acquire, packaged so a machine can apply them for you.

So the honest promise is two-layered. If your resource is common, it's probably already a menu click away, or about to be. If it's the bespoke thing only your shop runs, it's a short, guided build — not a fork, not a feature request, not a wait. Either way the outcome is the same: a native node in your palette, and one more entry the rest of the ecosystem can install after you.

An ecosystem, not a pile of integrations

Because a plugin targets the protocol rather than one product, the capabilities people build stop being one-off integrations and start being a shared library. A plugin someone writes for their own vector database is — with no extra effort — a node anyone else on the runtime can install. There's a catalog for exactly this: a place plugins are listed so they can be found and installed into any Inflowenger-based system, the way an extension store is the front door to a browser's ecosystem.

The difference between a platform with an extension menu and one without is the difference between a tool and an ecosystem. Without it, every new capability is a negotiation with the maintainers and a wait for the next release. With it, the platform grows sideways, continuously, driven by the people closest to each problem — and it grows safely, because every installed capability meets the runtime at the same governed seam. A plugin's decisions are edges on the diagram, its context access is scoped, its work is traced onto the canvas. Installing one adds a feature; it doesn't add a blind spot. (The mechanics of that governance — how a plugin lives inside the harness rather than across a boundary from it — are the subject of the plugins-versus-MCP piece, and worth reading if you want the architecture under the experience.)

And the catalog is filling in fast. The plugin-catalog roadmap is currently pointed straight at the databases — so there's a very high probability that within about ten days of this writing, effectively every well-known database has an inflowv1 plugin ready to install: the vector stores, the document stores, Postgres, the lot. If your database is on that list, the bring-your-own-database example above may not even be work you have to do — it may already be one entry in a menu away. Which is the whole promise of the ecosystem arriving on a schedule: the integrations show up before most people get around to asking for them.

And we'll keep you current on it. Each week, this blog will publish a short update on what's newly landed in the catalog — the plugins added since the last one, so you can see the palette growing in near real time and know when the node you've been waiting for is finally one install away.

The one-paragraph version

A plugin is a seamless connection between a flow and a resource you already run — a database, a queue, an internal API, a SaaS. Extending most platforms to reach one means becoming a maintainer: fork, learn the internals, merge, redeploy. Flomorphic replaces all of that with an install. Plugins have their own protocol and SDK, they carry their own configuration UI so their authors never touch the platform's frontend, and they arrive through a menu that registers them straight into the node palette — the way a browser extension arrives through a menu and shows up in your toolbar. Because a plugin targets the Inflowenger runtime rather than any one product, it's written once and installable everywhere the runtime runs, in almost any environment. And when the resource you need isn't listed — some ClickHouse, some store only your shop runs — building the plugin for it is a short, guided task, because the SDK repo ships a cookbook and a SKILL.md that let a coding agent author it for you. Common resources are already a menu click away; the bespoke one is a cheap build. Extend it like an extension. Then let everyone else install what you built.

Plugin SDK (docs, cookbook, and the SKILL.md): github.com/Inflowenger/go-plugin-sdk

Plugin catalog: github.com/Inflowenger/plugin-catalog

Concepts and docs: inflowenger.com/flomorphic

Repo: github.com/FloMorphic/getting-started

Want the architecture beneath the install experience? Start with Two Ways to Extend an Agent Platform, and the memory layer a bring-your-own-database plugin usually feeds is Your Company Doesn't Need Its Own LLM. It Needs a Brain.