Skip to content
Platform > Plugins

Plugins

A plugin adds a capability to 3forge Enterprise, such as a datasource adapter, a feed handler, an authenticator, or a REST endpoint, without changing the installation itself. Plugins ship as bundles that are copied into the plugins/ directory and picked up when the server starts.

Features

  • Install from a single file: copy the bundle you received into plugins/, unextracted, and restart.
  • Keep dependencies apart: each bundle loads in isolation, so the libraries inside one bundle do not clash with the server's or another bundle's.
  • Enable by default, or choose: a new plugin is enabled wherever its plugin list contains *, and any plugin can be excluded with ! and its ID.
  • Switch off any plugin: exclude a plugin by its ID to stop it being used without uninstalling it. The shipped configuration already does this for the SHELL datasource, which can run commands on the host.
  • See exactly what loaded: list every bundle, every registered plugin, and the plugins enabled in each component from the admin console, including the property that controls each one.
  • Find a plugin's ID without guessing: the startup log and the admin console both show the ID a bundle registered, which is the name configuration needs.
  • Diagnose from the log: 3 log lines trace a bundle from file to running plugin, and every failure has an exact error message to search for.

Overview

Plugins are how most optional capability reaches a deployment. Datasource adapters, Relay feed handlers, authentication methods, Web panels, AI providers, and REST endpoints are all plugins, and 3forge Enterprise ships 58 of them built in.

Three terms are used throughout this section:

  • Bundle: the archive a plugin ships in, a .tar.gz, .zip, or .jar file. It is installed whole and never extracted. A vendor may call it an add-on, a connector, or an extension.
  • Plugin type: the kind of plugin, such as DATASOURCE or RELAY_FEEDHANDLER.
  • Plugin ID: the short, case-sensitive name a plugin registers under, such as KAFKA. The ID often differs from the bundle's file name, and it is the name configuration uses.

The server reports both together as TYPE>ID, e.g: RELAY_FEEDHANDLER>KAFKA.

A plugin passes through 2 states:

  • Registered: the server found it in a bundle at startup. Every registered plugin is listed, whether or not anything uses it.
  • Enabled: at least one component, such as the Center, the Relay, or the Web, created it because the plugin list for its type includes it. Only enabled plugins do anything.

A plugin can be registered and not enabled. The shipped configuration does this deliberately for the SHELL datasource, which is registered on every startup and excluded from use.

Where to go next

Each plugin's own settings and usage, such as which Kafka topics to read, are specific to that plugin and are not covered in this section.

What this section does not cover

  • Writing a plugin: building your own plugin is not covered here.
  • Which bundles are available to you: the client portal lists the bundles assigned to your account.
  • Migrating an existing install's plugins: see What's New in 3forge Enterprise.
  • Authentication plugins, and plugins that control which hosts may connect: these are configured through the Security section.

Note

Check with 3forge support before relying on a plugin bundle that is not assigned to your account.