Cluster nodes is the control surface for trusted internal nodes in a multi-node Callaba deployment. Teams use it when one engine should act as the primary control point, when a child node should join the fleet, or when a node should be disabled cleanly without guessing what still depends on it.
This module is about safe topology management in production. It helps operators decide which nodes should participate, how they should trust each other, and how to attach or detach a node without turning the cluster relationship into tribal knowledge.
The most important production rule is simple: these nodes are internal infrastructure. The dashboard itself warns against using public IP addresses here, because the goal is a stable internal node mesh, not an exposed internet-facing control path.
The useful presets here follow real fleet roles: a primary control node, a connected slave node that uses a child-node token, and a test node for validation or rehearsal before a broader rollout.
{
"name": "Primary cluster node",
"host": "10.20.0.10",
"node_type": "CLUSTER_NODES_TYPE_MASTER",
"active": true
}
{
"name": "Istanbul slave node",
"host": "10.20.0.25",
"node_type": "CLUSTER_NODES_TYPE_SLAVE",
"api_token": "<child_node_jwt_token>",
"active": true
}
Use the create flow for a slave node when another machine should participate as part of the same operational system rather than as an unrelated standalone instance.
Use detachNode, stop, or remove when a node must be taken out of service cleanly before maintenance, relocation, or topology changes.
Use a dedicated test-node role when a team needs safe validation capacity without blurring the line between production ownership and experimentation.
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.
curl --request POST \--url http://localhost/api/clusterNodes/create \--header 'x-access-token: <your_api_token>' \--header 'Content-Type: application/json' \--data '{"name": "Primary cluster node","host": "10.20.0.10","node_type": "CLUSTER_NODES_TYPE_MASTER","active": true}'
Use this when a child node should join the trusted internal fleet and needs the child-node API token so attachment can succeed cleanly.
curl --request POST \--url http://localhost/api/clusterNodes/create \--header 'x-access-token: <your_api_token>' \--header 'Content-Type: application/json' \--data '{"name": "Istanbul slave node","host": "10.20.0.25","node_type": "CLUSTER_NODES_TYPE_SLAVE","api_token": "<child_node_jwt_token>","active": true}'
Use this when a node should be provisioned for validation, rehearsal, or isolated checks before it becomes part of a production path.
curl --request POST \--url http://localhost/api/clusterNodes/create \--header 'x-access-token: <your_api_token>' \--header 'Content-Type: application/json' \--data '{"name": "Test validation node","host": "10.20.0.40","node_type": "CLUSTER_NODES_TYPE_TEST","active": false}'
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.
curl --request POST \--url http://localhost/api/clusterNodes/create \--header 'x-access-token: <your_api_token>' \--header 'Content-Type: application/json' \--data '{"name": "Istanbul slave node","host": "10.20.0.25","node_type": "CLUSTER_NODES_TYPE_SLAVE","api_token": "<child_node_jwt_token>","active": true}'
The create call confirms acceptance with a success-shaped response.
{"success": true}
Use this method when the UI or an operator needs a quick count of registered cluster nodes without loading the full list.
curl --request POST \--url http://localhost/api/clusterNodes/getCount \--header 'x-access-token: <your_api_token>' \--header 'Content-Type: application/json' \--data '{}'
Total number of registered cluster nodes currently visible to the authenticated user.
{"count": 2}
Use this method to list the current cluster topology that the instance knows about. It is the fastest way to confirm which nodes are registered, which role each node has, and whether the fleet view still matches the intended production layout.
Optional page size for the node list.
Optional offset for paginated listing.
Optional sort descriptor. The dashboard store uses { created: 1 } by default.
curl --request POST \--url http://localhost/api/clusterNodes/getAll \--header 'x-access-token: <your_api_token>' \--header 'Content-Type: application/json' \--data '{"sort": {"created": 1},"limit": 20,"skip": 0}'
The backend returns the known cluster nodes as a bare array of node objects.
[{"_id": "681300000000000000000001","id": "681300000000000000000001","name": "Istanbul slave node","host": "10.20.0.25","node_type": "CLUSTER_NODES_TYPE_SLAVE","active": true,"created": "2026-03-24T19:00:00.000Z","modified": "2026-03-24T19:00:00.000Z","success": true}]
Use this method when one node needs to be inspected or edited in full, especially before attachment, detachment, or a role change.
Identifier of the node you want to inspect.
curl --request POST \--url http://localhost/api/clusterNodes/getById \--header 'x-access-token: <your_api_token>' \--header 'Content-Type: application/json' \--data '{"id": "681300000000000000000001"}'
The backend returns the stored node fields for the requested id.
{"_id": "681300000000000000000001","id": "681300000000000000000001","name": "Istanbul slave node","host": "10.20.0.25","node_type": "CLUSTER_NODES_TYPE_SLAVE","active": true,"created": "2026-03-24T19:00:00.000Z","modified": "2026-03-24T19:00:00.000Z","success": true}
Use this method when a node host, role, token, or activation state must be corrected without recreating the node from scratch.
Identifier of the cluster node being updated.
The update contract mirrors create and reuses the same host, type, token, and activation fields.
curl --request POST \--url http://localhost/api/clusterNodes/update \--header 'x-access-token: <your_api_token>' \--header 'Content-Type: application/json' \--data '{"id": "681300000000000000000001","name": "Istanbul slave node updated","host": "10.20.0.26","node_type": "CLUSTER_NODES_TYPE_SLAVE","api_token": "<child_node_jwt_token>","active": true}'
The backend confirms that the node update was accepted.
{"success": true}
Use this method when a registered node should return to active service after maintenance, validation, or a planned pause.
Identifier of the node to activate.
curl --request POST \--url http://localhost/api/clusterNodes/start \--header 'x-access-token: <your_api_token>' \--header 'Content-Type: application/json' \--data '{"id": "681300000000000000000001"}'
The backend confirms that the node was enabled successfully.
{"success": true}
Use this method when a node should remain registered but should no longer participate in the active cluster until the team is ready to bring it back.
Identifier of the node to disable.
curl --request POST \--url http://localhost/api/clusterNodes/stop \--header 'x-access-token: <your_api_token>' \--header 'Content-Type: application/json' \--data '{"id": "681300000000000000000001"}'
The backend confirms that the node was disabled successfully.
{"success": true}
Use this method when a registered node should be attached into the active cluster relationship and treated as part of the current trusted topology.
Identifier of the node that should be attached into the active cluster relationship.
curl --request POST \--url http://localhost/api/clusterNodes/attachNode \--header 'x-access-token: <your_api_token>' \--header 'Content-Type: application/json' \--data '{"id": "681300000000000000000001"}'
The backend confirms that the node attachment step completed successfully.
{"success": true}
Use this method when a node should stay registered for reference but must be detached from the active cluster relationship before maintenance, testing, or removal.
Identifier of the node that should be detached from the active cluster relationship.
curl --request POST \--url http://localhost/api/clusterNodes/detachNode \--header 'x-access-token: <your_api_token>' \--header 'Content-Type: application/json' \--data '{"id": "681300000000000000000001"}'
The backend confirms that the node detachment step completed successfully.
{"success": true}
Use this method when a node relationship should be removed entirely from the cluster inventory rather than merely paused.
Identifier of the node to remove.
curl --request DELETE \--url http://localhost/api/clusterNodes/remove \--header 'x-access-token: <your_api_token>' \--header 'Content-Type: application/json' \--data '{"id": "681300000000000000000001"}'
The backend confirms that the node was removed successfully.
{"success": true}