Etcd

Open source alternative to HashiCorp Consul

52.6K stars
Apache-2.0
Active this week
Last commit today

Last verified Nov 7, 2026

Manage distributed cluster state with a strongly consistent key-value store that uses the Raft algorithm to survive network partitions and machine failures.

Visit website GitHub52.6K Deploy on Hostinger

Read the full breakdownWho it is for, how it works, trade-offs, the quick start and the FAQ

who it's for

Who Etcd is for#

Kubernetes Cluster Operators

If you are deploying or operating a Kubernetes cluster, Etcd is not optional: it is the control plane's data store. Knowing how to back it up, restore it, and monitor quorum health is a core operational skill for any team managing Kubernetes in production.

Skip if:

You are using a managed Kubernetes service where the control plane, including Etcd, is managed by the cloud provider.

Teams Building Distributed Systems

If your application needs distributed locks, leader election, or a consistent configuration store shared across a fleet of nodes, Etcd provides the building blocks. The lease and watch primitives give you the foundation for these patterns without writing your own consensus logic.

Skip if:

Your application is a single-node service with no distributed coordination requirements.

Service Registry Builders

Teams building a lightweight service registry can use Etcd's watch mechanism to propagate service registration and deregistration events in real time. Each service writes its address to a leased key; when the service stops refreshing the lease, the key expires and downstream watchers see the removal automatically.

Skip if:

You need DNS-based service discovery or health checks out of the box; consider a tool that includes those natively.

the problem

The problem it solves#

Distributed systems need a small, authoritative store for coordination data: which node is the current leader, what the cluster membership looks like, and what state each component has committed. Solving this with a general-purpose database or a shared file system means accepting inconsistency during network splits or node failures, which produces split-brain scenarios where separate parts of a cluster make conflicting decisions and corrupt shared state.

The hardest part is not the steady state; it is making the right decision when a network partition separates some nodes from the leader. Without a consensus-based store, teams either accept eventual consistency and risk conflicting writes, or add custom quorum logic on top of a datastore that was not designed for it. Neither path gives the guarantees needed to run critical infrastructure at scale, which is why Kubernetes, locksmith, Doorman, and similar systems are built on top of a dedicated coordination store.

how Etcd solves it

How it solves it#

Raft Consensus Replication

Every write is replicated to a majority of cluster nodes before being acknowledged. If a network partition or node failure occurs, Etcd holds an election and elects a new leader from the surviving quorum without data loss. The Raft algorithm ensures that only one leader can commit writes at any time, preventing split-brain state corruption.

gRPC API with HTTP/JSON Proxy

The primary API is gRPC, with HTTP/JSON proxied through a gateway for tools that prefer curl or standard HTTP clients. This means you can read and write keys from any language with a gRPC client and also interact with the cluster directly from the command line using etcdctl, the bundled CLI tool.

Real-Time Key-Change Watching

Clients can watch individual keys or key prefixes and receive a notification the moment a value changes. Kubernetes uses this mechanism to distribute state updates across controllers: when a pod is scheduled, the watch fires and the relevant nodes react. The watch stream remains open across leader elections.

TLS and Client Certificate Authentication

Etcd supports full TLS encryption for both client-to-server and server-to-server traffic, with optional client certificate authentication. This means you can require every client to present a trusted certificate before reading or writing keys, which is the production security baseline for clusters handling secrets.

Key TTL and Lease-Based Expiration

Keys can be attached to a lease with a time-to-live. When the lease expires, all keys attached to it are automatically deleted. This is the primitive that enables distributed locks and leader election: a node holds a lease and refreshes it; if the node fails, the lease expires and another node can claim the key.

strengths · trade-offs

Strengths and trade-offs#

Strengths

Apache 2.0 LicenseEtcd is licensed under Apache 2.0, an OSI-approved license with no restrictions on commercial use or distribution. You can run it internally, modify it, include it in a product, or build a business on top of it without any licensing fees or required disclosures beyond attribution.
CNCF Graduated ProjectEtcd is a graduated Cloud Native Computing Foundation project, meeting the CNCF's production-readiness standards: active maintenance, a defined governance model, and security review processes. The maintainer team holds weekly community and triage meetings and publishes meeting recordings to the official YouTube channel.
Proven at Kubernetes ScaleKubernetes uses Etcd as the sole storage backend for all cluster state: nodes, pods, services, secrets, and config maps. With 52,617 GitHub stars and in-production use at thousands of organizations, the operational edge cases are well-documented and community-tested.

Trade-offs

-Narrow Use Case by DesignEtcd is not a general-purpose database and is not designed for large values, high-cardinality analytics, or write-heavy workloads beyond its benchmarked limits. The recommended use is small configuration and coordination data; storing application content, user data, or large blobs in Etcd degrades cluster performance and is explicitly discouraged in the documentation.
-Production Requires a Multi-Node ClusterA single-node Etcd instance has no fault tolerance: any failure takes down the store. Production use requires at least three nodes to maintain a quorum. Managing a three-node cluster, handling upgrades, and monitoring quorum health adds operational work that teams often underestimate when first deploying it.
-Main Branch is UnstableThe README explicitly states the main branch may be in an unstable or even broken state during development. For production, you must use a tagged release from the releases page, not the tip of main. Teams that pin dependencies to main branches will encounter build failures.

versus alternatives

Etcd vs alternatives#

Etcd vs HashiCorp Consul

Etcd and Consul both offer distributed key-value storage with consensus-backed consistency. The differences emerge in scope and operational model.

Core Focus

Etcd is a single-purpose coordination store: strongly consistent key-value reads and writes, a watch mechanism for change notification, and nothing else. Its narrow scope is a design choice that keeps the operational model simple and the consistency guarantees strict.

Consul, as described in its catalogue entry, adds service discovery, health checking, service mesh support, and multi-datacenter coordination on top of its key-value store. Teams who need a single tool that handles both coordination and service discovery may find Consul's broader feature set fits their use case.

Consistency Model

Etcd's Raft implementation ensures that every read returns the most recently committed write. This strict consistency is what Kubernetes requires for its control plane: a pod update must be visible to all controllers immediately.

Consul's key-value store offers multiple consistency modes. Its default mode may return slightly stale reads from a follower node; its consistent mode forwards all reads to the leader at the cost of added latency.

Deployment Complexity

Both tools use a three-node minimum cluster for fault tolerance. Etcd deploys as a single Go binary with no external dependencies beyond the nodes themselves. Consul uses an agent architecture where each node runs a Consul agent in either client or server mode, adding more moving parts to the deployment. Teams who want to minimize the operational surface of their coordination layer generally find Etcd's deployment simpler.

Licensing

Etcd is Apache 2.0, an OSI-approved license with no commercial-use restrictions. Consul's licence terms are outside the scope of this comparison; review Consul's current terms before choosing it for a self-hosted production deployment.

When Etcd Fits

Etcd fits teams running Kubernetes (it is already embedded in the control plane), teams building distributed coordination primitives such as locks and leader election, and teams who want the smallest-footprint consensus store with no service discovery overhead.

Consider Consul when your team needs service discovery, health checking, service mesh, and multi-datacenter support as a package alongside key-value coordination.

install · quick start

Quick start#

bash

Download pre-built binaries for Linux, macOS, and Windows from GitHub Releases: https://github.com/etcd-io/etcd/releases/latest

tech stack · detected from GitHub

What it's built on#

Languages: Go
Infrastructure: Kubernetes

frequently asked

FAQ#

Is etcd only for Kubernetes, or can I use it independently?

Etcd predates Kubernetes and is used independently by distributed systems like Doorman, locksmith, and vulcand, as listed in the README. Kubernetes is by far the largest consumer, but any application that needs a strongly consistent, distributed configuration or coordination store can use Etcd directly through its gRPC API or one of the language client libraries documented at etcd.io/docs/latest/integrations.

What is the minimum cluster size for a fault-tolerant production deployment?

Three nodes is the minimum for a fault-tolerant production cluster. Raft requires a quorum, so a three-node cluster can survive one node failure. A five-node cluster can survive two. A single-node cluster has no fault tolerance: any failure makes Etcd unavailable and your Kubernetes cluster or dependent services will halt. The etcd documentation covers multi-node clustering setup in detail.

How fast is etcd in practice?

The README and product website both document a benchmark of 10,000 writes per second. The website also notes thousands of writes per second as typical. Actual throughput depends on hardware, network latency, and value size; small coordination keys on modern hardware will often exceed these benchmarks, while large values or high-latency networks will fall below them.

Does etcd encrypt data at rest?

Etcd encrypts traffic in transit using TLS, with optional client certificate authentication. Encryption at rest is not built into Etcd itself; it relies on disk-level or filesystem-level encryption provided by the host operating system or storage layer. Teams running Kubernetes can configure Kubernetes-level secret encryption, which encrypts the data before it reaches Etcd.

How do I back up etcd data?

The etcdctl CLI tool, which ships with Etcd, includes a snapshot command that creates a consistent backup of the whole keyspace. For Kubernetes deployments, backing up Etcd is part of the standard cluster backup procedure. The etcd documentation at etcd.io/docs covers snapshot and restore procedures. Because Etcd holds the authoritative state of a Kubernetes cluster, regular snapshots are a production requirement.

also worth a look

Similar open-source tools#

Bugsink

Alternative toSentry

Self-hosted error tracking, drop-in compatible with all Sentry SDKs.

2,166 GitHub stars
Licence PolyForm Shield License 1.0.0

Convex

Alternative toFirebase

Reactive backend with TypeScript functions and real-time sync

12,778 GitHub stars
Licence FSL-1.1-Apache-2.0

Alchemy

Alternative toPulumi Cloud

Type-safe cloud infrastructure and app logic in one TypeScript program

1,883 GitHub stars
Licence Apache-2.0

Kopia

Alternative toVeeam Data Platform

Encrypted, deduplicated backups to any cloud or local storage

14,595 GitHub stars
Licence Apache-2.0

Frankenphp

Alternative toLiteSpeed Web Server

PHP app server with automatic HTTPS, HTTP/3, and worker mode.

11,516 GitHub stars
Licence MIT

Lazyrsync

InDeveloper Tools

Rust TUI for rsync with saved profiles, dry-run diff, and SSH.

987 GitHub stars
Licence MIT

by category

Open source tools in these categories#

Self-host Etcd on a Hostinger VPS

Keep it running 24/7, even when your laptop is off. A Hostinger VPS gives it a server of its own.

01
Choose a plan
Starts from $6.49/mo
02
Apply
Extra 10% off yearly plans
03
Install Etcd
On a server that stays on
04
Start building
Focus on the app, not the server

Deploy on Hostinger

Inbox Zero

Alternative toSuperhuman

AI email assistant that drafts replies and clears your inbox

12,915 GitHub stars
Licence AGPL-3.0
#Email

rakazo

Alternative toGrok Bot

AI teammates you own: your keys, your model, your machine.

7,028 GitHub stars
Licence Apache-2.0
#AI Agents

SnitchFeed

Live monitoring on LinkedIn, X, Reddit & more. Agentic social listening for startups.

Marketing & Growth

Advertise your product

The projects we add and every new guide. Free, unsubscribe any time.

Find open source alternatives to paid software

Etcd vs HashiCorp Consul

Etcd and Consul both offer distributed key-value storage with consensus-backed consistency. The differences emerge in scope and operational model.

Core Focus

Consistency Model

Deployment Complexity

Licensing

When Etcd Fits

Consider Consul when your team needs service discovery, health checking, service mesh, and multi-datacenter support as a package alongside key-value coordination.