Gravity

Fully-replicated network infrastructure, honestly reviewed. No marketing fluff — just what you get when you replace your Pi-hole and dnsmasq with something built to survive a node going down.

TL;DR

• What it is: Open-source (GPL-3.0) DNS, DHCP, and TFTP server cluster backed by etcd — one binary that handles your entire internal network stack with full replication across nodes [website][GitHub].
• Who it’s for: Homelabbers and small-business network admins who have outgrown single-instance Pi-hole or AdGuard Home and need something that keeps working when one node dies. Not a tool for non-technical users.
• Cost savings: Replacing commercial network management appliances (Infoblox, BlueCat) with Gravity costs you a few VPS instances or spare hardware at ~$5–15/mo each. Enterprise DNS/DHCP licensing routinely runs thousands per year. Price data for hosted alternatives not available in reviewed sources.
• Key strength: True multi-node replication without an external database. The etcd cluster is the database — no separate Postgres or MySQL, no primary-replica lag, no split-brain on network partition [website][GitHub].
• Key weakness: 908 GitHub stars puts this firmly in “promising indie project” territory. No independent third-party reviews were found for this tool. Documentation is sparse in places, and the project depends heavily on a single maintainer.

---

What is Gravity

Gravity is a unified DNS, DHCP, and TFTP server that uses etcd as its backing store, making every configuration change and lease automatically replicated across all nodes in a cluster. The GitHub description is direct: “Fully-replicated DNS and DHCP Server with ad-blocking powered by etcd” [GitHub].

What separates Gravity from the typical homelab DNS stack is that replication is built into the architecture from day one, not bolted on. Pi-hole replication requires third-party scripts. AdGuard Home replication is an unofficial community hack. Gravity’s cluster is first-class: you spin up multiple instances, they discover each other via etcd, and DNS caches, DHCP leases, and all configuration stay in sync automatically [website].

The DNS layer is built on the same codebase as CoreDNS and Blocky, which means the resolution engine is production-tested at scale — Gravity isn’t reinventing the DNS wheel, just adding a replicated management plane on top of it [website]. Ad-blocking is included and the blocking lists are replicated across the cluster so every node has the same filtering behavior.

DHCP is similarly integrated: when Gravity hands out a lease, it automatically creates a matching DNS record. A device joins your network, gets an IP from DHCP, and DNS resolves its hostname immediately — no manual entries, no sync delay [website]. The server can also import existing leases from Microsoft’s DHCP server, which is a practical detail for people migrating off Windows Server network services.

TFTP is the third role, mainly useful for network booting (PXE) and storing router and switch configuration files. This is a niche feature but one that matters for anyone maintaining managed switches or running a lab that boots diskless nodes [website].

Metrics are built-in via Prometheus and the README includes a Grafana dashboard screenshot — you get cluster-level visibility into DNS query rates, DHCP lease counts, and per-node load without installing any additional observability stack [GitHub].

---

Why people choose it

No independent third-party reviews were found for Gravity as of this writing — with 908 stars it hasn’t yet attracted the review-site coverage that larger projects have. The case for choosing it over alternatives comes from the project’s own positioning and what’s absent in the tools it’s competing against.

The gap Gravity fills. Pi-hole and AdGuard Home are single-instance tools. You can run two Pi-holes with cron-based sync scripts, but if the sync fails, one node diverges silently. Gravity’s entire design assumption is that you have multiple nodes and they must stay consistent [website]. If that’s your actual situation — two Raspberry Pis, two VMs across two sites, anything where you want no single point of failure — Pi-hole’s architecture works against you and Gravity’s works for you.

The etcd choice. Using etcd instead of SQLite or Postgres is opinionated. etcd is what Kubernetes uses to store cluster state — it’s designed for exactly this problem: keeping configuration consistent across distributed nodes with automatic leader election and conflict resolution. The trade-off is that etcd adds operational weight for a single-node install. If you’re only ever running one instance, you’re carrying the overhead of a distributed consensus system for no benefit. Gravity makes most sense at two nodes or more [website][GitHub].

The CoreDNS foundation. Building the DNS layer on CoreDNS rather than writing a custom resolver means Gravity inherits CoreDNS’s plugin ecosystem and battle-tested behavior under load. DNS is not a problem you want to solve yourself [website]. The Blocky codebase addition brings the ad-blocking functionality from a project with an established community and maintained block lists.

Wake-on-LAN from the UI. A small but practically useful feature — you can send WOL signals to devices directly from Gravity’s web interface [website]. This is the kind of thing that shows the project understands homelab workflows, not just server-room deployments.

---

Features

Based on the project website and README [website][GitHub]:

DNS:

• Recursive and forwarding DNS resolution
• Built-in caching, replicated across all cluster nodes
• Configurable ad/privacy blocking (block lists)
• Can be configured as a forwarder to an existing DNS server — useful for incremental migration
• Zone management via web UI

DHCP:

• Full DHCP server with automatic DNS record creation on lease assignment
• Lease replication across all cluster nodes
• Import of existing DHCP leases and reservations from Microsoft DHCP Server
• Wake-on-LAN signal delivery from the web UI

TFTP:

• TFTP server for PXE network booting
• Storage for router/switch configuration files

Cluster and replication:

• etcd-backed — no external database required, etcd is the database
• All nodes are equal — no primary/secondary concept, no manual failover
• Multi-site capable without VPN or database replication setup
• Network discovery across cluster members

Observability:

• Built-in Prometheus metrics for all cluster nodes
• Pre-built Grafana dashboard included in the repository
• Per-client query visibility without additional tooling

What’s missing from the data:

• API documentation is not covered in available sources
• Authentication/RBAC details not available in reviewed material
• High-availability guarantees (minimum etcd quorum requirements) not documented in reviewed sources

---

Pricing: SaaS vs self-hosted math

Gravity is self-hosted only — there is no managed cloud offering. Pricing comparisons are against commercial alternatives and the cost of running the hardware.

Running Gravity:

• Software: $0 (GPL-3.0) [GitHub]
• Hardware per node: a Raspberry Pi ($35–80 one-time) or a low-end VPS ($4–6/mo on Hetzner or Contabo)
• Minimum useful setup: 2 nodes for actual redundancy — ~$8–12/mo in VPS costs or two spare SBCs

Commercial alternatives:

• Infoblox DDI (DNS, DHCP, IPAM): enterprise pricing, typically $10,000–$50,000+/year for a mid-size organization. Exact pricing not publicly available.
• BlueCat Address Manager: similar enterprise tier, no public pricing.
• Microsoft DHCP + DNS (Windows Server): included in Windows Server licensing, but Windows Server licenses run $500–6,000 depending on edition and OEM vs. retail.

More realistic homelab comparisons:

• Pi-hole on a Raspberry Pi: $0 software + hardware cost. No replication.
• AdGuard Home on a VPS: $0 software + ~$4–6/mo per instance. No native replication.
• Technitium DNS Server: $0, more feature-rich DNS management than Pi-hole, but no DHCP cluster replication.
• dnsmasq: $0, minimal, no UI, configuration is text files.

For a home network or small business that just needs one box, Gravity’s cost is identical to Pi-hole — free software, whatever your hardware costs. The value calculation only applies when you genuinely need replication across two or more nodes, at which point Gravity’s built-in cluster beats the manual sync approaches for Pi-hole and AdGuard Home.

---

Deployment reality check

No independent deployment walkthroughs were found in reviewed sources. The following is based on project documentation and the tool’s architecture [website][GitHub][docs].

What the project says about installation: The docs page at gravity.beryju.io/docs/install/ exists and is linked from the homepage. The project targets small to medium networks and positions itself as suitable for multi-site deployment [docs].

What you realistically need:

• Linux hosts (VMs, bare metal, or SBCs like Raspberry Pi)
• Docker or the ability to run Go binaries directly
• Two or more nodes if you want the replication features that justify choosing Gravity over simpler alternatives
• A network where you can set DNS and DHCP servers — this means touching router configuration
• Basic familiarity with how DNS and DHCP work, because you will be debugging them

What can go wrong:

• etcd quorum: with two nodes, you can lose consensus if one goes down — etcd technically prefers odd node counts (1 or 3). Running two Gravity nodes for “redundancy” may not behave as expected under failure scenarios. This is a fundamental distributed systems property, not a Gravity bug, but it’s worth understanding before deploying.
• DNS is critical path infrastructure. If your Gravity cluster goes down, nothing on your network can resolve hostnames. This is true of any DNS server, but it’s worth internalizing before you replace a working Pi-hole setup.
• DHCP conflicts: running Gravity DHCP alongside an existing DHCP server (your router’s built-in DHCP, for example) will cause IP conflicts. You need to disable the existing DHCP server.
• GPL-3.0 license: if you’re building a commercial product or appliance that bundles Gravity, GPL-3.0 requires you to open-source your modifications. This matters for commercial embedded use cases.

For non-technical users: This is not a tool you hand to someone unfamiliar with networking concepts. Setting DNS and DHCP for a network requires understanding what those services do, knowing how to change router settings, and having a plan for what happens when the server is unreachable. The web UI makes ongoing management easier, but initial setup requires network administration knowledge.

Realistic time estimate for someone with Linux and networking experience: 1–3 hours for a basic single-node install, half a day for a properly configured two-node cluster with etcd.

---

Pros and cons

Pros

• Replication is the whole point, and it works. Built on etcd, not bolted-on sync scripts. If you’ve fought with Pi-hole sync breaking silently, this architecture difference matters [website][GitHub].
• Unified stack. DNS + DHCP + TFTP + ad-blocking in one binary, one web UI, one place to look when something breaks. No coordinating three separate daemons [website].
• CoreDNS and Blocky foundation. The DNS engine is not custom code — it inherits the stability of two established open-source projects [website].
• Automatic DNS from DHCP. Hostname resolution just works when a device joins. No manual DNS entries when your devices get new IPs [website].
• Built-in Prometheus metrics and Grafana dashboard. Observability is included, not an afterthought [GitHub].
• WoL from UI. Small convenience feature that shows attention to homelab workflows [website].
• No external database. Simpler operational model — etcd handles both consensus and storage [website][GitHub].

Cons

• 908 stars / one primary maintainer. This is early-stage software. No evidence of commercial backing, no enterprise SLA, no dedicated support team. Bus-factor is real here.
• No independent third-party reviews found. Unlike Pi-hole or AdGuard Home, there’s minimal community write-up to validate real-world behavior at scale.
• etcd overhead for small setups. Single-node Gravity carries etcd complexity with none of the replication benefit. Pi-hole or AdGuard Home is simpler if you’re running one instance.
• GPL-3.0 restricts commercial embedding. If you want to bundle this in a product or appliance, you inherit the copyleft obligations.
• TFTP is niche. For most users this feature is irrelevant; it’s not a minus exactly, but don’t pick Gravity because of TFTP unless you specifically need PXE booting.
• Documentation gaps. The docs exist but are not comprehensive based on reviewed materials. API coverage and advanced configuration are likely require reading source code or community forums.
• Not for non-technical users. DNS/DHCP management is inherently a networking task. This tool doesn’t abstract that complexity away.

---

Who should use this / who shouldn’t

Use Gravity if:

• You’re running or want to run DNS and DHCP across two or more nodes and need them to stay in sync automatically.
• You have multiple sites (home + office, two physical locations) and want consistent DNS/DHCP without a VPN tunnel to a central server.
• You’re currently fighting with Pi-hole sync scripts or running two independent AdGuard Home instances with diverging configs.
• You want integrated Prometheus metrics without setting up external exporters.
• You’re migrating off Windows Server DHCP and want something that can import existing leases.

Skip it (use Pi-hole or AdGuard Home instead) if:

• You have one location, one server, and just want DNS-level ad-blocking. Pi-hole and AdGuard Home are more mature, better documented, and have larger communities.
• You’re non-technical and want a guided setup experience with active community forums.

Skip it (use Technitium DNS Server instead) if:

• You want a feature-rich DNS server with a good UI but don’t need DHCP clustering or etcd replication. Technitium is more mature and better documented.

Skip it (use ISC Kea + BIND instead) if:

• You’re running a production network at scale with compliance requirements and need software with commercial support options, active CVE patching history, and enterprise documentation.

Skip it (stay on your router’s built-in DNS/DHCP) if:

• Your network is a home with one router and you’ve never needed to look at a DNS query log. The complexity of Gravity is not justified.

---

Alternatives worth considering

• Pi-hole — the most popular self-hosted DNS ad-blocker. Massive community, excellent documentation, single-instance design. Use it if you don’t need clustering.
• AdGuard Home — cleaner UI than Pi-hole, also single-instance by default, unofficial sync options exist. Good choice for one-box setups.
• Technitium DNS Server — full-featured DNS server with a web UI, more DNS management capabilities than Pi-hole, no built-in DHCP cluster.
• CoreDNS — the engine Gravity builds on. Extremely configurable via plugins, but raw configuration — no web UI, not for non-technical operators.
• dnsmasq — the classic lightweight DNS/DHCP combo. No UI, no replication, but simple, stable, and in use everywhere.
• ISC Kea — modern DHCP server from the Internet Systems Consortium, supports High Availability mode, more complex to configure but production-grade.
• Blocky — the ad-blocking DNS component Gravity is partially based on. Use it standalone if you want fast DNS filtering without DHCP management.

For the homelab user specifically choosing between Pi-hole and Gravity: the question is whether you need replication. If yes, Gravity. If no, Pi-hole has years of community content, integrations, and debugging guides that Gravity can’t match at 908 stars.

---

Bottom line

Gravity solves a real problem — replicated DNS and DHCP without an external database — in a clean, opinionated way. The etcd-backed architecture is genuinely sound, and the feature set (DNS, ad-blocking, DHCP with auto-DNS, TFTP, metrics) covers the entire internal network stack. For a homelab or small business with multiple sites or nodes, it’s worth evaluating seriously.

The honest caveat is that with under 1,000 GitHub stars and no independent reviews available, you’re betting on a project that hasn’t been stress-tested by a wide community. Pi-hole and AdGuard Home have years of Reddit threads, forum posts, and troubleshooting guides that Gravity lacks. If you hit an edge case, you may be reading source code rather than finding an answer on Stack Overflow.

For the right use case — multi-node, multi-site, want real replication — Gravity is the most elegant open-source option in this category. For everyone else, the simpler tools are simpler for a reason.

---

Sources

1. Gravity — Official Website — gravity.beryju.io. https://gravity.beryju.io
2. Gravity — GitHub Repository (GPL-3.0, 908 stars) — github.com/beryju. https://github.com/beryju/gravity
3. Gravity — Documentation — gravity.beryju.io. https://gravity.beryju.io/docs/

Note: No independent third-party reviews of Gravity (beryju/gravity) were available in the sources provided for this article. The four external articles supplied ([1]–[4]) reference unrelated products sharing the “Gravity” name (Gravity Forms, GravityKit, Gravity Software, and Antigravity drone) and were not cited.