Skip to main content

​
What are Plugins?

Plugins extend Noxus with capabilities the core platform doesn’t ship. A plugin is a small, installable package that adds new building blocks to your deployment — the nodes you drop into flows, the services you connect, the events that start automations, and the sources your knowledge bases ingest from — without anyone forking or changing the platform itself.
Plugins turn external systems and custom logic into first-class Noxus components, so you can focus on what a flow should do instead of on integration plumbing.

​
What a plugin contributes

A single plugin can bundle any combination of four component types:

​
Nodes come in two flavors

Noxus nodes exist in two generations, and plugins can provide either:
  • V2 nodes (preferred) are connector-free. A node’s inputs are bindable configuration fields — you set a literal value or reference an upstream node’s output — mirroring how the platform’s own modern nodes work.
  • V1 nodes are the legacy edge-connector style, wired by dragging connections between handles. They remain supported for existing V1 flows.
Both kinds are declared the same way in a plugin and both feel native in the editor; the platform keeps them as distinct entities so each renders and validates correctly.

​
Integrations carry the credentials

When a plugin’s node needs to talk to an authenticated service, an integration defines the credential schema, validates it, and stores it securely. Credentials are scoped per workspace — each workspace connects its own — and the platform injects them into the node only at execution time.

​
How a plugin becomes usable

Everything the platform needs to know about a plugin is captured in its manifest — a description of the plugin’s components, their configuration, and its dependencies, derived directly from the plugin’s code. When a plugin is installed, Noxus reads this manifest, stores it, and resolves the plugin’s components from it on demand. The manifest is the contract: it drives the node palette and the auto-generated configuration forms, and it always reflects the code that is actually running.

​
Isolated by design

Plugin code never runs inside the Noxus platform. Each installed plugin runs in its own isolated sandbox — its own environment and dependencies — as a long-lived worker the platform talks to over a private channel. This isolation is deliberate:
  • A plugin can use any dependencies it likes without clashing with the platform.
  • A misbehaving plugin can’t destabilize the rest of Noxus.
  • Plugins reach platform data (files, credentials) only through controlled, scoped interfaces — never with a general key to the platform.
Plugins are installed once per deployment by an administrator and are then available across the whole deployment; only integration credentials are connected per workspace.

​
Using Plugins

Once a plugin is installed, its components behave like any built-in feature: drop its nodes into flows and co-workers, connect its integrations in workspace settings, and wire its triggers to automate runs.

Nodes

Use plugin nodes inside flows and co-workers to read, write, and act on third-party data. Configure inputs and outputs, map credentials, and run.

Integrations

Connect external services through the plugin’s integration — the platform handles authentication and secure credential storage.

Triggers

Start flows from external events polled by the plugin. Configure the trigger, connect the service, and automate.

​
Next Steps