Elasticd coordinates service ownership across Linux nodes. Define your preferred owners and required health checks; Elasticd coordinates who can take over and when.
ILLUSTRATIVE FAILOVERA preferred owner. Fresh health reports.
When a service fails, moving its address is only part of the job. You also need to know which node is eligible, who is authorized to take over, and when the previous owner has safely stepped aside.
Define the preferred owner and required health checks for each resource. Different services can run on different eligible nodes, with ownership coordinated through embedded Raft.
External checks report through a local health socket. Elasticd validates those reports and requires fresh, acceptable evidence before a node is eligible to own a resource.
An eligible node still needs a valid ownership grant. Expiring leases and takeover safeguards control when a successor can act, allowing time for the previous owner and its network effects to clear.
Reconcile service addresses locally, publish routes through built-in BGP, or connect a supported external publisher. Health reporting, ownership, and network publication each have a clear responsibility.
Explore the documentation
THE PEOPLE BEHIND THE PROJECTWe are building elasticd for the people responsible for keeping services available. Its architecture and source are open to inspection, with clear responsibilities and explicit failure behavior. Elasticd is in pre-alpha development; follow the project as it takes shape.
See how ownership works, explore the documentation, and follow development.
