Skip to main content
A plugin is the implementation behind a node type. Yukta ships 34 of them in three roles: triggers start a workflow, processors transform, route and call out, and terminals end a branch. This page lists every type at a glance. Each group has its own page with every option, the output ports and a JSON example.
The plugin set and the options of each plugin are pre-beta (0.0.1-SNAPSHOT) and may change before v0.1.0.

Type strings

Use a type string exactly as written below. Lookup is exact and case-sensitive, so branch and Branch are not found. Almost every type is upper case with underscores. CONTENT-FILTER is the one type that uses a hyphen.

Triggers

A trigger has no input. It produces the first message of a run. See Triggers.

Processors

Processors read messages from their parents and emit messages on named output ports.

Routing and flow

See Routing and flow.

Transform

See Transform.

External I/O

See External I/O.

AI

See AI plugins.

Decisions

See Decision plugins.

Terminals

A terminal consumes messages and has no output ports. See Terminals.

Options every node accepts

Besides the options of its plugin, a node’s config can carry:
  • timeoutSeconds: the node’s idle timeout in seconds. Without it the node uses the default timeout of its plugin, which is 30 seconds unless the plugin page says otherwise. See Time limits.
  • engine: the reserved engine policy object (retry, error routing, deadline, edge buffer, placement). See Failure handling.
Plugins read their own options only. Where an option accepts ${...} variables, its description says so; see Variables and expressions for the syntax. Options that take an expression use the expression language described on that page.

Choosing which plugins a build includes

Triggers, terminals and the routing, transform and flow processors (BRANCH, FILTER, SPLITTER, AGGREGATE, RECIPIENT_LIST, DELAY, LOOP_PREDICATE, LOOP_STREAM, SUB_WORKFLOW, WAIT_FOR_SIGNAL, MAPPER, VALIDATE, CONTENT-FILTER, KV_STORE) are always part of the server. The rest are optional and chosen when the server is built, with the build property yukta.plugins:
An unknown module name stops the build. The modules and the types they provide: Leaving a module out removes its capability from the server entirely. A deployment that does not need to run commands, SQL or scripts can leave those modules out.

When a type is not installed

A workflow that uses a type the server does not have is rejected when it is validated, with the message Plugin not found for type: <TYPE>, and its node never runs. MAPPER in SCRIPT mode is rejected the same way, with a message that names script-js, when that module is missing. See Validation and versions. To see what a running server has, list its plugins:
The response lists each installed type with its category (TRIGGER, PROCESSOR or TERMINAL). The web UI plugin catalogue and the MCP tools list_plugins and get_plugin_details show the same information.

Reading a plugin’s option schema

GET /api/plugins/{type} describes one installed plugin. It answers 404 when the type is not installed.
This example is abridged. The response also carries a timestamp and the card design the web UI draws for the node. A plugin with no configuration, such as API_TRIGGER or CONSOLE_TERMINAL, returns an empty configSchema.
PROCESS_EXECUTOR, SQL_QUERY, FILE_READ, FILE_WRITE, HTTP_REQUEST and the SCRIPT mode of MAPPER act on the server’s host or network with the server’s permissions. Treat authorship of workflows as a trusted operation. See Security.