Cluster nodes
Use Cluster nodes to attach, activate, inspect, and remove Engine instances in a multi-node Callaba deployment.
Choose this whenOne deployment needs trusted regional or additional Engine nodes.
Use another module whenUse a single Engine instance when distributed capacity or regional placement is not required.
/api/clusterNodes/createBefore you start
All methods require an administrative x-access-token. Nodes must be reachable over the required network paths, use the intended role, and have unique identity and address information.
What you can do
create,update,getAll,getCount, andgetByIdmanage node records.attachNodeanddetachNodechange cluster membership.startandstopcontrol a registered node.removedeletes a node record that is no longer needed.
Example workflow
- Create the node with its role and reachable address.
- Attach it to the intended cluster.
- Start it and verify its state before assigning work.
- Stop and detach it before maintenance or removal.
Common use cases
- Add a regional processing node for an event near its contribution feeds.
- Keep a test node separate from production assignments.
- Drain and detach a node for maintenance without deleting the cluster.
Limits and troubleshooting
Incorrect roles, duplicate addresses, unreachable hosts, or missing network permissions can prevent attachment or startup. Detaching or stopping a node can affect resources assigned to it, so move or stop dependent work first.
Next steps
After the node is active, create the ingest or processing resources that should run on the cluster.
Attach a worker to a Callaba cluster
Create the node record, attach it to the reviewed master, and start it only after network and version checks pass.
- Create the nodeRegister the reviewed host and role.
POST /api/clusterNodes/create - Attach itJoin the node to the intended cluster relationship.
POST /api/clusterNodes/attachNode - Start the workerStart only after the attachment and health checks succeed.
POST /api/clusterNodes/start
Cluster methods require administrative access. Test reachability and compatibility before moving production workloads.
Use this method to register a new internal node in the cluster. In production, the create call matters when the fleet is expanding, when a child node should become part of the trusted topology, or when a clean test node should be prepared ahead of a rollout.
For slave nodes, the child-node API token is part of that trust handshake. The dashboard also warns the operator not to use a public IP here because this relationship is intended for internal infrastructure.
Use this when one internal node should act as the main coordination point for the cluster and the rest of the fleet should align around it.
Use this when a child node should join the trusted internal fleet and needs the child-node API token so attachment can succeed cleanly.
Use this when a node should be provisioned for validation, rehearsal, or isolated checks before it becomes part of a production path.
Dashboard label: Node name.
Human-readable internal node name.
Dashboard label: Type.
Real product values are CLUSTER_NODES_TYPE_MASTER, CLUSTER_NODES_TYPE_SLAVE, and CLUSTER_NODES_TYPE_TEST.
Dashboard label: Host.
Internal node address. The dashboard warns operators not to use a public IP here.
Dashboard label: API token.
Child-node JWT token used for slave-node attachment flows. It is only relevant when the node type is CLUSTER_NODES_TYPE_SLAVE.
Dashboard label: Enabled.
Controls whether the node should be active right after provisioning.
The create call confirms acceptance with a success-shaped response.