DEV.co
Open-Source DevOps · 0xERR0R

blocky

Blocky is a lightweight DNS proxy and ad-blocker written in Go that runs on local networks. It blocks ads and malware domains, supports modern DNS protocols (DoH, DoT, DoQ), and integrates with Prometheus and databases for monitoring and logging.

Source: GitHub — github.com/0xERR0R/blocky
6.8k
GitHub stars
289
Forks
Go
Primary language
Apache-2.0
License (OSI-approved)

Key facts

Objective fields from the source. Values we can't verify are shown as “Unknown” rather than guessed.

FieldValue
Repository0xERR0R/blocky
Owner0xERR0R
Primary languageGo
LicenseApache-2.0 — OSI-approved
Stars6.8k
Forks289
Open issues46
Latest releasev0.33.0 (2026-06-30)
Last updated2026-07-07
Sourcehttps://github.com/0xERR0R/blocky

What blocky is

Go-based DNS proxy offering multi-protocol support (DNS/UDP, DNS/TCP, DoH, DoT, DoQ, DoH3), customizable block/allow lists with regex, DNSSEC validation, caching, and upstream resolver distribution. Provides REST API, CLI, and Prometheus metrics with optional CSV/SQL query logging.

Quickstart

Get the blocky source

Clone the repository and explore it locally.

terminalbash
git clone https://github.com/0xERR0R/blocky.gitcd blocky# follow the project's README for install & configuration

Need it deployed, integrated, or customized instead? DEV.co ships production installs.

Best use cases

Home Network Ad-blocking & Parental Control

Self-hosted DNS filter for residential networks requiring per-client group policies (kids, smart home, etc.). Replaces Pi-hole with lower resource footprint and modern protocol support.

Privacy-focused Small Business/Homelab DNS

Organizations needing transparent DNS logging, DNSSEC validation, and multi-upstream resolver distribution without external data collection. Runs on Raspberry Pi, ARM, or standard x86 servers.

Kubernetes/Containerized DNS Infrastructure

Community Helm charts and Docker multi-arch images enable stateless DNS caching and filtering in microservices environments with Prometheus observability.

Implementation considerations

  • Single binary deployment and stateless architecture simplify initial setup, but YAML configuration requires technical knowledge and careful block/allow list curation.
  • Memory footprint is low, but caching effectiveness and performance depend on query patterns; stress-test with actual network traffic before production rollout.
  • Supports multiple upstream resolvers with random distribution for privacy; configure at least 2–3 public resolvers and test DNSSEC validation if enabled.
  • Logging to CSV or SQL databases enables historical analysis but requires separate storage infrastructure; plan retention policies to avoid disk bloat.
  • Multi-architecture builds (x86-64, ARM, MIPS) work on Raspberry Pi and routers, but ARM image stability and third-party router integration should be verified per device.

When to avoid it — and what to weigh

  • Enterprise-Grade DNS Management Required — Lacks centralized management console, audit trails, or compliance-specific features (e.g., HIPAA, SOC 2). Single-maintainer project may not meet enterprise SLA expectations.
  • Large-Scale Recursive Resolver Replacement — Designed for local network DNS proxy, not authoritative DNS or large recursive resolver deployments. No geographic distribution, failover clustering, or anycast support documented.
  • Guaranteed Commercial Support Needed — Community-maintained project with single maintainer accepting donations. No commercial support contracts, SLA guarantees, or vendor backing available.
  • Graphical UI Preference — Configuration via YAML files and REST API only. No built-in web dashboard for non-technical users; third-party dashboards require Prometheus + Grafana setup.

License & commercial use

Licensed under Apache License 2.0 (Apache-2.0), a permissive OSI-approved license allowing commercial use, modification, and distribution with minimal restrictions. Requires LICENSE file and copyright notice preservation in derivative works.

Apache-2.0 permits commercial use in products and services. However, the project is community-maintained with no vendor backing. Organizations using Blocky commercially should: (1) audit the license compliance of dependencies, (2) maintain local patches and security updates independently, (3) acknowledge that no commercial support contract is available.

DEV.co evaluation signals

Editorial assessment — not user reviews. Directional, with an explicit confidence level.

SignalAssessment
MaintenanceActive
DocumentationAdequate
License clarityClear
Deployment complexityLow
DEV.co fitGood
Assessment confidenceHigh
Security considerations

No security audit or formal vulnerability disclosure process documented. DNSSEC validation is available but requires upstream resolver support. Supports modern DNS protocols (DoH, DoT, DoQ, DoH3) for encrypted upstreams. User data is not collected or transmitted. Source code is open for review. Threat model and security guidelines should be reviewed independently before deploying in security-sensitive environments.

Alternatives to consider

Pi-hole

Established ad-blocker with GUI dashboard and larger community, but heavier resource footprint and more opinionated feature set. Pi-hole may be preferred if web UI and mature ecosystem are priorities.

AdGuard Home

Full-featured DNS ad-blocker with modern UI, larger team, and commercial backing. Heavier resource usage; choose AdGuard if centralized UI and commercial support are required.

Unbound

Lightweight recursive resolver with DNSSEC support and minimal dependencies. Lacks built-in ad-blocking and requires separate filtering layers; better for advanced DNS control than turnkey ad-blocking.

Software development agency

Build on blocky with DEV.co software developers

Evaluate Blocky for your home lab or small business network. Confirm DNS upstream resolver strategy, plan block list curation, and test Prometheus/database logging before production.

Talk to DEV.co

Related open-source tools

Surfaced by semantic similarity across the DEV.co open-source index.

Related on DEV.co

Explore the category and the services that help you build with it.

blocky FAQ

Does Blocky collect user data or telemetry?
No. The project explicitly states it collects no user data, telemetry, or statistics. DNS queries and logs remain local to the network unless you configure external database logging.
Can I run Blocky on a Raspberry Pi?
Yes. Blocky has low memory footprint and supports ARM architecture. Multi-arch Docker images and single binary releases are available; test on your specific Pi model and OS before production use.
Does Blocky support redundancy or high availability?
Not documented. Blocky is stateless and designed for single-node deployment. HA would require external load balancing, multiple instances, and client failover logic outside the project scope.
What is the process for reporting security vulnerabilities?
Not clearly stated in the provided data. Review the GitHub repository for a SECURITY.md file or contact the maintainer directly. No formal CVE or advisory process is documented.

Software development & web development with DEV.co

From first prototype to production, DEV.co delivers software development services around tools like blocky. Our software development agency staffs experienced software developers and web developers for custom software development, web development, integrations, and ongoing support across open-source devops and beyond.

Ready to Deploy Blocky?

Evaluate Blocky for your home lab or small business network. Confirm DNS upstream resolver strategy, plan block list curation, and test Prometheus/database logging before production.