Cloudflare routes over 280 billion DNS queries every single day across its global edge network. Now imagine a dedicated top-level domain built specifically for the growing community of developers running services on their own hardware. The proposed .self top-level domain aims to do exactly that—provide a standardized, predictable namespace for self-hosted infrastructure.
TL;DR: The proposed
.selftop-level domain offers a dedicated naming structure for self-hosted environments, simplifying local network configuration. With over 60% of developers now running some form of local server infrastructure,.selfeliminates manual localhost conflicts by providing automatic DNS resolution for private services.
What Is the .self Top-Level Domain?
The .self top-level domain is a proposed special-use domain name designed exclusively for self-hosted applications and private network infrastructure. According to DNS fundamentals, the Domain Name System functions as the internet’s primary directory, translating human-readable names into IP addresses that computers use to communicate. The .self extension applies this principle to local environments.
Instead of typing http://192.168.1.100:8080 to access a home media server, users could navigate to media.self. The system resolves this locally. This approach mirrors how .local operates for mDNS (Multicast DNS) discovery, but .self targets a different use case entirely—it serves self-hosted services that need stable, memorable identifiers without relying on external domain registrars.
The technical community has discussed similar concepts for years. Projects like n8n demonstrate how self-hosted automation platforms create their own internal routing structures for webhooks and API endpoints. A dedicated TLD formalizes this pattern. It gives every self-hosted service a predictable home.
The Internet Engineering Task Force (IETF) previously reserved .localhost for loopback addresses in RFC 6761. The .self proposal extends this philosophy. It covers broader self-hosted scenarios where services run on separate physical machines within a local network. Think of a home lab with multiple Raspberry Pi devices. Each could receive its own .self subdomain without conflicting with global DNS resolution.
How Does DNS Routing Work for .self Domains?
DNS routing for .self domains operates through local resolution rather than global root servers. When a device queries homeassistant.self, the request never leaves the local network. A local DNS resolver—typically running on a router or a dedicated service like Pi-hole—intercepts the query and returns the appropriate private IP address.
This process relies on DNS override configuration. Network administrators configure their resolver to recognize .self as a local zone. The resolver then answers all queries for that zone from its local records instead of forwarding them to upstream providers like Cloudflare’s 1.1.1.1 or Google’s 8.8.8.8.
For automated environments, this creates interesting possibilities. Workflow automation tools like n8n can register webhook endpoints under .self domains during deployment. A CI/CD pipeline deploying a new container version could automatically update the local DNS record to point api.self to the new container’s IP address.
The resolution chain works as follows:
- Application requests
n8n.selfthrough the system’s DNS client - The query reaches the configured local DNS resolver
- The resolver matches
.selfagainst its local zone configuration - Instead of forwarding to root servers, it returns the internal IP (e.g.,
10.0.0.15) - The application connects directly to the local service
This architecture eliminates dependency on external DNS providers for internal services. It also improves resolution speed dramatically. Local queries resolve in microseconds compared to the milliseconds required for round-trip queries to public resolvers.
Why Is Self-Hosting Gaining Traction in 2026?
Self-hosting has moved far beyond hobbyist experimentation into mainstream developer practice. Several converging factors drive this shift. Cloud service costs continue climbing, with major providers implementing regular price increases throughout 2025. Privacy regulations like GDPR and CCPA impose strict data handling requirements that complicate cloud deployments. Hardware capability has also exploded.
A $35 Raspberry Pi 5 now delivers performance that rivals enterprise servers from a decade ago. Developers recognize this. Why pay monthly fees for cloud hosting when a single-board computer handles the workload for free?
The gaming community illustrates this trend vividly. A recent case documented by GRYOnline.pl involved a developer who built and maintained a dedicated 24/7 home server specifically to preserve a rescue simulation mod after official servers faced shutdown. This wasn’t a simple hobby project. The creator invested in real hardware, configured persistent network access, and committed to ongoing maintenance. The motivation was preservation—keeping a unique experience alive through self-hosted infrastructure.
This same impulse drives broader adoption. Developers want control over their data, their uptime, and their costs. Open-source platforms like Nextcloud, Home Assistant, and Jellyfin have matured into production-quality software. They demand proper infrastructure.
The .self domain proposal arrives at exactly the right moment. It addresses the naming problem that every self-hoster eventually encounters. How do you assign memorable, conflict-free names to dozens of local services without purchasing individual domain names or memorizing IP addresses?
What Are the Technical Requirements for Using .self?
Running .self domains requires three core infrastructure components. First, a local DNS resolver capable of zone override configuration. Second, properly configured client devices that delegate DNS queries to the local resolver. Third, self-hosted services with static or DHCP-reserved IP addresses on the local network.
For the DNS resolver, popular choices include Pi-hole, AdGuard Home, and dnsmasq. These tools allow administrators to define custom zones. A configuration for dnsmasq might look like this:
# /etc/dnsmasq.d/self.conf
address=/self/10.0.0.0
local=/self/
expand-hosts
domain=selfThis configuration tells dnsmasq to treat all .self queries as local. The address directive provides a catch-all response, while individual host entries can override specific subdomains. For example:
# Individual service mappings
address=/n8n.self/10.0.0.15
address=/homeassistant.self/10.0.0.20
address=/jellyfin.self/10.0.0.25
address=/vaultwarden.self/10.0.0.30Client configuration requires setting the local resolver as the primary DNS server. Most home routers allow this through DHCP options. When a device joins the network, it automatically receives the resolver’s IP address and begins querying it for all DNS requests.
| Component | Minimum Requirement | Recommended Setup |
|---|---|---|
| DNS Resolver | dnsmasq on any Linux machine | Pi-hole on dedicated hardware |
| Network | Single subnet with DHCP | VLAN segmentation for services |
| Hardware | Any networked device | Raspberry Pi or mini PC |
| Router Support | Custom DNS via DHCP | DNS override + port forwarding |
| Client OS | DNS-over-HTTPS disabled | DoH disabled + local DNS trusted |
One critical detail: DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT) can bypass local resolvers entirely. Browsers like Firefox and Chrome increasingly enable these protocols by default. Users must either disable DoH/DoT on client devices or configure the local resolver to handle encrypted DNS queries.
How Does .self Compare to Traditional Localhost Setups?
Traditional localhost development relies on the loopback address 127.0.0.1 and the .localhost TLD. This works adequately for single-service development. A developer runs a Node.js application on port 3000 and accesses it at localhost:3000. Simple enough.
Problems emerge with multi-service architectures. Microservice applications might require ten or more simultaneous services. Port conflicts become inevitable. Developers resort to memorizing arbitrary port numbers—localhost:8080 for the API, localhost:5432 for PostgreSQL, localhost:6379 for Redis. The cognitive overhead grows quickly.
The .self domain eliminates this class of problems entirely. Each service receives a clean, named endpoint. Instead of localhost:8080/api/v1, the same service becomes api.self. Reverse proxy tools like Traefik or Nginx Proxy Manager can route requests based on the hostname, directing traffic to the appropriate container or process.
Consider a typical home lab running multiple services:
n8n.self— automation workflows on port 5678grafana.self— monitoring dashboards on port 3000prometheus.self— metrics collection on port 9090gitea.self— self-hosted Git on port 3001nextcloud.self— file synchronization on port 80homeassistant.self— smart home control on port 8123jellyfin.self— media streaming on port 8096mqtt.self— message broker on port 1883
With traditional localhost, accessing these services requires typing the IP and port every time. With .self, each service gets a memorable name that resolves automatically. Bookmarks work cleanly. SSL certificates become manageable through wildcard generation. The entire experience improves.
What Security Implications Come With .self Domains?
Security remains the primary concern for any self-hosting setup. The DNS system, which translates human-readable domain names into IP addresses, operates as a distributed hierarchy where trust is delegated from root servers down to individual resolvers (Verseo, DNS documentation). When a resolver queries a domain, it traverses this hierarchy to retrieve authoritative answers.
For .self domains, the trust model shifts entirely. Instead of relying on public certificate authorities and global root servers, validation happens locally. The machine itself acts as its own authority.
This eliminates certain attack vectors. DNS hijacking through compromised registrars becomes irrelevant. Man-in-the-middle attacks against external DNS infrastructure lose their leverage. The attack surface shrinks to the local network and the host machine itself.
However, new risks emerge. If a local resolver is compromised, an attacker could redirect .self traffic. Local certificate management requires discipline — self-signed certificates must be generated and rotated carefully.
What does this mean practically? Users must secure their host operating systems rigorously. Network segmentation helps isolate self-hosted services from untrusted devices.
The DNS resolution process, as described by Verseo, involves iterative queries through caching layers. With .self, these caches exist only on the local machine or network, reducing exposure to cache poisoning from external resolvers but concentrating risk on local infrastructure.
Can Automation Tools Like n8n Benefit From .self?
Automation platforms like n8n thrive on clear service discovery. When workflows need to connect to local databases, APIs, or microservices, addressing becomes critical. The n8n self-service portal pattern demonstrates how administrators build internal tooling that orchestrates dozens of local endpoints (Askomputer, n8n guide).
With .self domains, each service gets a predictable, human-readable address. Instead of memorizing port numbers — localhost:3000 for the API, localhost:5432 for the database — administrators reference api.self and db.self. This clarity reduces configuration errors significantly.
Configuration management improves dramatically. Environment files become readable. Debugging gets faster.
The n8n documentation highlights how self-service portals centralize administrative tasks. When those portals reference .self addresses, the entire automation chain benefits from consistent naming. Webhook endpoints, cron-triggered jobs, and inter-service communication all use the same predictable namespace.
Consider a typical n8n workflow that pulls data from a local API, transforms it, and writes to a local database. Each step references a service. With .self, those references are self-documenting.
Additionally, when n8n workflows execute HTTP requests, the local resolver handles .self lookups without external network calls. This reduces latency. It also means workflows continue functioning during internet outages — a genuine operational advantage for home lab environments and offline development setups.
How Do .self Domains Impact Game Server Preservation?
Game preservation faces a silent crisis. When publishers shut down official servers, communities fragment. The story of one mod creator who built a 24/7 home server to keep a rescue simulation mod alive illustrates this perfectly (GRYOnline.pl). Without dedicated community infrastructure, entire game modes simply vanish.
The creator ran a persistent server from their own home, ensuring players could still experience the mod’s content. This required stable addressing — players needed to find the server reliably.
Here, .self domains offer structural support. Community members hosting game servers can assign memorable addresses within their local networks or VPN meshes. A retro gaming group could configure halo-ce.self or battlefield-1942.self for their persistent sessions.
This matters more than it sounds. Server browsers and direct-connect features rely on DNS resolution. When players can resolve a game server through a .self address configured on the community VPN, connection friction drops to near zero.
For preservation projects, documentation benefits too. Setup guides can reference stable .self addresses instead of dynamic IPs or complex port-forwarding instructions. New community members join faster.
The home server model described by GRYOnline.pl — where a single dedicated machine runs continuously — maps directly onto the .self use case. The server exists locally. The domain should too.
What Are the Limitations of the .self TLD?
No technology is universal. The .self TLD carries specific constraints that potential adopters must understand before committing.
First, .self domains do not resolve on the public internet. A visitor typing blog.self into a browser from an unconfigured network will see an error. The domain exists only where local resolution is configured.
Second, certificate authorities like Let’s Encrypt will not issue TLS certificates for .self addresses. They cannot — these domains are not present in the public DNS root. Users must rely on self-signed certificates, which trigger browser warnings unless manually trusted.
Third, mobile devices present challenges. Phones connecting to a home Wi-Fi network can use .self domains if the router advertises the local DNS resolver. But on cellular data, resolution fails entirely.
Fourth, sharing links becomes awkward. Sending a colleague a URL like https://photos.self/vacation-2025 only works if their device can resolve the address. This limits collaboration scenarios.
Fifth, tooling compatibility varies. Some applications hardcode checks against public TLD lists and may reject .self addresses during validation. Developers must test their specific stack.
Sixth, there is no central registry governing .self. Conflict resolution between services claiming the same name depends entirely on local configuration priority.
Seventh, monitoring and alerting tools that expect globally resolvable domains may require custom configuration or exemptions for .self entries.
Eighth, documentation and onboarding for non-technical users demands extra effort — the concept of a local-only domain requires explanation.
| Limitation | Impact | Workaround |
|---|---|---|
| No public resolution | External access blocked | Use VPN or tunnel for remote access |
| No CA-issued certificates | Browser warnings | Manually trust self-signed certs |
| Mobile network gaps | Cellular resolution fails | Configure split-horizon DNS |
| Tooling validation errors | Some apps reject .self | Patch validation or use aliases |
How Can Developers Get Started With .self Today?
Getting started requires three components: a local DNS resolver, a domain configuration, and service bindings.
Most modern operating systems support local DNS resolution through configurable resolvers. On Linux, systemd-resolved or dnsmasq handle custom TLD assignment. On macOS, the /etc/resolver/ directory allows per-TLD resolver specification. Windows users can configure conditional forwarding through DNS Manager or use tools like Acrylic DNS Proxy.
The setup process follows a consistent pattern across platforms.
- Install a local resolver — dnsmasq, CoreDNS, or Pi-hole all support custom TLDs
- Configure the .self zone — map
.selfto127.0.0.1or your local subnet - Set service addresses — assign
api.self,db.self,cache.selfas needed - Update your hosts file — for single-machine setups,
/etc/hostsentries suffice - Generate local certificates — use
mkcertto create a local CA and issue trusted certs - Configure your applications — point database connections, API URLs, and service endpoints to .self addresses
- Test resolution — run
dig api.selfornslookup api.selfto verify - Document your setup — record which services map to which .self addresses for team reference
For Docker users, the process integrates cleanly. A docker-compose.yml can reference .self addresses directly when the host resolver is configured. Containerized services resolve each other through the local DNS without external calls.
Developers using Kubernetes can leverage CoreDNS Custom Zones to define .self within the cluster. This brings the same naming clarity to orchestrated environments.
The key principle: start small. Configure one service on .self, verify it works, then expand.
Frequently Asked Questions
Does .self replace the traditional localhost address?
No, .self complements rather than replaces localhost. The traditional loopback address 127.0.0.1 maps to localhost through the hosts file on virtually every operating system, and the DNS resolution process ensures this mapping persists globally (Verseo, DNS documentation). The .self TLD extends this concept by allowing multiple named services — api.self, db.self, cache.self — to coexist on different ports or IP addresses within the local network.
Can I register a .self domain publicly like a .com?
No, .self is not part of the public DNS root and cannot be registered through ICANN-accredited registrars. The DNS hierarchy delegates trust from root servers through TLD registries to individual domain owners (Verseo), but .self operates outside this chain entirely. It functions strictly as a local or private network namespace, resolved only by configured DNS servers within your infrastructure.
Do .self domains work across different operating systems?
Yes, but configuration methods differ by platform. The DNS system relies on recursive resolvers that query authoritative servers in sequence (Verseo), and every major OS supports custom resolver configuration. Linux uses systemd-resolved or dnsmasq, macOS supports per-TLD resolvers via /etc/resolver/, and Windows offers DNS Manager or third-party tools like Acrylic DNS Proxy for custom zone assignment.
Is .self secure enough for hosting sensitive personal data?
Security depends entirely on local configuration discipline. The DNS resolution process involves multiple caching and forwarding layers (Verseo), and with .self these layers exist only on infrastructure you control — reducing external attack surface but concentrating risk locally. You must secure the host OS, manage self-signed certificates properly, and implement network segmentation to protect sensitive services effectively.
Summary
The .self TLD addresses a real gap in the self-hosting ecosystem — providing clean, memorable naming for services that never needed global visibility.
Key takeaways:
- Local-first by design —
.selfdomains resolve only where configured, eliminating external DNS dependency and reducing attack surface from registrar compromise and cache poisoning - Automation-friendly — tools like n8n benefit from predictable service addressing, making workflow configurations readable and reducing inter-service connection errors
- Preservation enablement — game server communities running persistent home setups, as documented by GRYOnline.pl, gain stable addressing that simplifies player onboarding
- Platform-agnostic — every major operating system supports custom DNS zones, though configuration methods vary between Linux, macOS, and Windows
- Not a public replacement —
.selfcomplements traditional domains for internal use but cannot serve public-facing websites or receive CA-issued TLS certificates
For developers, homelab enthusiasts, and self-hosting advocates, .self offers a structured approach to local naming that beats memorizing port numbers. The setup requires initial effort, but the payoff in clarity and maintainability justifies the investment.
If you are building a self-hosted stack, consider adopting .self for your internal services. The configuration is straightforward, the benefits compound as services multiply, and the isolation from public DNS provides genuine security advantages.