Dora NodaA domain is often treated as the last boring checkbox before a deployment: buy it, point a record at the service, let HTTPS appear. The Human-Centered Computing Foundation (HCCF) is asking a more ambitious question with its proposed .self top-level domain: could the name itself become public infrastructure for personal, self-hosted services?
It is a compelling direction. But it also helps to name the boundary precisely. A PaaS can automate deployment, routing, and certificates today once an operator controls a domain and its DNS. A future .self registry could change how people acquire and govern that domain—but it would not erase the hosting, security, identity, or abuse work on the other side of the dot.
Here is the practical split.
| A self-hosted platform can do this with any domain today | A future .self registry would have to provide or define this |
|---|---|
Map app.example.com to a load balancer or gateway with A, AAAA, or CNAME records | Give a person a .self subdomain at no cost and decide its lifecycle |
| Prove control with ACME HTTP-01 and issue a certificate for an individual hostname | Offer a supported delegation or DNS API model so operators can complete ACME validation |
Issue *.apps.example.com with ACME DNS-01, then route many app hostnames through one gateway | Decide whether people receive a zone, a single name, delegated child names, or only a managed record set |
| Deploy an application, terminate TLS, renew certificates, and remove records when an app is deleted | Enforce "one person, one subdomain," prevent squatting, and publish an appeal and recovery process |
| Connect a separate VPN, mail provider, or self-hosted mail stack | Operate or integrate any promised shared VPN and mail services—and absorb their security and abuse obligations |
That table is the decision aid for platform builders. .self may eventually lower the friction of getting a human-readable public name. It does not replace DNS control, certificate automation, or an operator's responsibility for the services that name reaches.
The proposal is a registry vision, not a deploy target
HCCF announced its campaign in June 2026 and says it is an approved participant in ICANN's Applicant Support Program (ASP). Its one-page .self overview describes a public-good TLD built for self-hosting: one free subdomain per person, no parking or resale, community-guided rules, shared VPN and mail services, and open-source clients for TLS generation, dynamic DNS, local DNS caching, mail, and VPN use. Those are meaningful product commitments, not just a new spelling for a web address. HCCF's announcement and proposal PDF are worth reading as a statement of intent.
They are not, however, proof that a usable .self zone exists. A TLD sits at one layer of a larger system:
- A registry operates the TLD's authoritative namespace and sets its rules.
- A registration policy decides who may receive a name, what evidence they must provide, and how disputes, recovery, and deletion work.
- DNS delegation gives the recipient—or a managed service—control over records below that name.
- Hosting and a PaaS run the app behind those records, route requests, issue certificates, and maintain availability.
Only the last layer is what a git-push PaaS normally owns. Conflating them creates a bad expectation: a friendly TLD can make the starting point more accessible, but it cannot make a service secure, reachable, or operated for its owner.
ICANN's process has several gates after an application
The timing matters. ICANN's 2026 new-gTLD application window ran from April 30 through August 12, and the program says it closed with more than 1,600 applications. HCCF's ASP participation means it has qualified for a support path; it is not a delegation decision, nor evidence by itself that a particular string has completed every application stage. The support program offers capacity assistance, pro bono services, counseling, and a 75–85% reduction in evaluation fees for qualifying applicants. ICANN's ASP overview is unusually clear about that distinction.
For any proposed string, the path is longer than "application accepted":
- ICANN performs pre-evaluation work and publishes application information on Reveal Day.
- Communities and eligible parties can submit feedback, objections, and appeals after the string is confirmed.
- ICANN evaluates the string and the applicant's operational and financial readiness. A similar or identical application can create a contention set.
- A successful applicant contracts with ICANN, completes technical onboarding and testing, then receives delegation into the root zone.
That sequence is set out in ICANN's applicant journey. It is why a platform team should treat .self as a capability to watch, not as a hostname to put in a production configuration. Until delegation, existing registrars and domains remain the practical path.
"One person, one subdomain" is the real product decision
Free allocation sounds simple until the system has to distinguish a person who lost access from a person creating a second identity, a domain squatter, or an abuser. This is not a criticism unique to .self; every scarce, durable identifier has a similar tension. What is different here is that the promise makes the allocation rule central to the product.
| Possible allocation approach | Sybil resistance | Privacy and exclusion cost | Operational consequence |
|---|---|---|---|
| Government-ID verification | High against casual duplicate sign-ups | High collection risk; excludes people without suitable documents or safe disclosure | Sensitive data handling, verification vendors, breach response, and a human appeals process |
| Payment, phone, or social-account proof | Moderate; familiar accounts can still be bought, shared, or excluded | Links identity to commercial intermediaries and excludes people without the accepted account | Ongoing anti-fraud tuning and dependency on third-party policies |
| Privacy-preserving credentials | Potentially strong if issued and revoked well | Lower disclosure at allocation time, but issuance itself must be broadly accessible | New protocol, issuer governance, recovery, and verifier interoperability work |
There is no honest way to fill this table with a universally best row. The trade-off needs a published policy: what data is retained, what qualifies as one person, how a name is reclaimed, what happens after death or loss of keys, and how a decision is appealed. HCCF's brochure states the intended rule, but it does not yet publish that operating policy. That is the work that will determine whether a public-good promise is credible in practice.
The other promises deserve the same specificity. Shared mail is not just a mailbox: it requires anti-spam operations, abuse handling, reputation management, account recovery, and a deliverability strategy. A VPN tunnel needs an authorization model, key rotation, bandwidth policy, and an incident response path. Bundling those services can improve the first-run experience, but each adds a security and support surface that a TLD registry must fund and run well.
Make the PaaS integration portable first
The best preparation is not a special .self integration. It is a domain workflow that already works with a conventional registrar and can accommodate a future registry if its policies permit it.
For a Kubernetes-backed or self-hosted PaaS, the checklist looks like this:
- Separate the zone from the application. Give the platform a delegated application zone such as
apps.example.com, rather than broad control of a personal apex domain. That makes ownership, revocation, and migration understandable. - Choose an ACME proof path. HTTP-01 works well when the gateway can serve the challenge on the public hostname. DNS-01 is needed for wildcards and is useful when an app cannot safely expose a challenge endpoint. Let's Encrypt documents the challenge trade-offs, including that wildcard issuance requires DNS-01. Its challenge guide is the canonical starting point.
- Use narrowly scoped DNS credentials. A certificate controller should receive only the permissions it needs to create challenge records. In cert-manager, an
Issuercan select DNS-01 solvers, including external providers through webhooks. The cert-manager DNS-01 documentation shows the supported shape. - Delegate
_acme-challengewhen necessary. A CNAME from the application's zone to a dedicated validation zone can isolate certificate automation from the rest of DNS. This is often safer than giving a deployment controller power over every record. - Choose wildcard versus per-app certificates deliberately. A wildcard makes routing many subdomains simple but creates a high-value private key and cannot cover arbitrary depth. Per-app certificates reduce shared-key scope but increase issuance and renewal activity. Record that decision in the platform's tenant model.
- Define deletion and transfer semantics. When an app disappears, remove routing and DNS records; when a tenant changes providers, let them move the delegated zone and reissue certificates. No TLD policy should turn a deployment platform into the permanent owner of a person's name.
Every item in that list works today. A delegated .self zone with a standard DNS API would fit it naturally. The unknowns are exactly the registry-specific items: whether .self permits DNS delegation, whether it offers record APIs, which names a person receives, and whether its allocation and recovery policy lets a PaaS act as a safe technical delegate.
The point is operator choice, not a new dependency
The attractive part of .self is not the string. It is the attempt to treat a durable personal name as public-interest infrastructure instead of inventory to speculate on. If HCCF reaches delegation and publishes an accountable allocation, recovery, DNS, mail, and abuse model, it could remove real friction for people who want a stable home for self-hosted services.
For now, the durable engineering choice is portable domain automation: standard DNS delegation, ACME, isolated credentials, and clean tenant exits. That approach lets a team use a domain from any registrar today and adopt .self later if its registry interface and policy earn trust. A human-first name should expand that choice—not make a self-hosted app depend on another opaque control plane.
Bex.co is the open-source, AI-native Render alternative: push a git repo and get a running HTTPS service on machines you own. Its value is in the deploy-and-operate layer; portable DNS and TLS automation keep the domain layer in the operator's hands. Star the repo on GitHub or deploy your first app today.
