Cluster nodes manage database and application membership. They do not promise automatic workload scheduling, geographic routing or seamless autoscaling.
Callaba self-hosted
The trusted Slave appears as the intended active cluster member and can be detached through the tested procedure.
See how the product worksBefore you start
Private network reachability between nodes.
Administrator API token for the node being attached.
Compatible Callaba versions and a current configuration backup.
Settings explained
These are the controls an operator needs to understand. Internal field names and implementation events are intentionally omitted.
Node identity
Describe the trusted member.
- Name
Operator-facing node name.
- Node type
Master, Slave or Test role supported by the UI.
- Private host
Reachable private address used between nodes.
Avoid a public address when a private path is available.- API token
Administrator token used to establish trusted management.
Treat it as a secret.- Active
Lifecycle state of the registered node.
Safe first workflow
- 01
Back up the current configuration and verify private network connectivity.
- 02
Create the node with its intended role, private host and administrator token.
- 03
Attach the node and wait for membership to settle.
- 04
Start it and verify reachability plus the expected database membership.
- 05
Test detach and recovery procedure outside a production incident.
Workflow examples
Add a trusted slave node
A self-hosted deployment needs a supported additional cluster member.
How to build it
- 1
Confirm compatible versions, backup and private connectivity.
- 2
Register the Slave with its private host and token.
- 3
Attach and start the node in a controlled window.
- 4
Verify node state and database membership before using it operationally.
Reattach a node after planned maintenance
A trusted cluster member was intentionally detached for host or network maintenance.
How to build it
- 1
Confirm that maintenance is complete and compare the node version, role and private address with the recorded baseline.
- 2
Verify private connectivity and the trusted token before changing membership.
- 3
Attach and start the existing node during the approved window.
- 4
Check the resulting membership and application health before returning the node to operational use.
Verify the result
- The node is reachable over the intended private path.
- Role and lifecycle state match the planned topology.
- Attach/detach operations produce the expected membership state.
Troubleshooting
Attach fails
Check- Check private reachability.
- Verify the node token and version.
- Confirm the role and current membership.
Correct trust or network prerequisites before repeating the attach action.