FreeDomain: a non-profit subdomain service where the repository is the product page

The repository is a service description, not a codebase

The tree at the root of this repository contains two entries: `README.md` and a `.github/` directory. There is no source directory, no dependency file, no build configuration, no releases and no detected language. The GitHub description field is the entire pitch, six words: a free domain for everyone.

That is unusual for a repository with a little over 2,100 stars, and it changes what an evaluation should look like. There is nothing to audit, nothing to fork for the server side, and no local copy of the allocation logic to read. The stars reflect adoption of a running service, and the README is the service's documentation. Reading it closely is the whole job.

One structural fact is worth flagging early: the GitHub metadata records no license for this repository and no license file appears in the tree. The README describes a non-profit operating model and a fiscal sponsorship, which are two different things from a software license. If you need to reuse anything here, the licensing position is unresolved rather than permissive, and the project should be asked directly.

Five extensions, two different access paths

The available extensions table is the core of the offer, and it divides cleanly by requirement. The `.int.yt` extension is public and open to anyone with four or more characters, registered instantly. Four other extensions are also public but carry a requirement listed as an IFP Key: `.nc.to`, `.gw.to`, `.rh.to`, and `.yn.to`.

The README does not define what an IFP Key is or how you obtain one. It appears as a bare requirement cell in the table with no accompanying section, no link, and no explanation of which of the four extensions share a single key or whether each needs its own. That is the single largest documentation gap in the repository, and it means a reader cannot tell in advance whether `.gw.to` is a fast path or an application process.

The homepage for the project is int.yt, and the four secondary links in the quick links section resolve to the official site, a management dashboard at dash.int.yt, a public WHOIS lookup at dash.int.yt/public-whois.php, and a Discord invitation. The presence of a public WHOIS endpoint is a genuine signal, since it means domain existence is queryable by anyone without an account, which is what makes the availability check in the signup flow possible in the first place.

Four steps to a name, with DNS delegation as step four

The documented path to a subdomain is four numbered steps. First, check availability using the WHOIS lookup. Second, create an account on the Intent Dashboard. Third, claim the domain through the user dashboard. Fourth, connect DNS by pointing the subdomain's nameserver records at your hosting provider.

Step four is where the documentation both helps and stops helping. It lists exactly two supported nameserver hosts, FreeDNS and Namecheap, and adds a note that Cloudflare support is coming soon. Since Cloudflare is the default DNS choice for a large share of new projects, and since a subdomain whose nameservers point elsewhere cannot simply have a CNAME bolted on from the Cloudflare side, that line determines who can use the service today. If your DNS already lives at Cloudflare, you are waiting on that roadmap item rather than configuring around it.

None of the four steps is described at the level of a field name or a URL, and there is no API documentation, no CLI, and no mention of automation. The repository presents this as a browser workflow through the dashboard and nothing more.

Short names are reviewed by hand to limit squatting

The default allowance is four or more characters, registered instantly with no review. Shorter names are handled the opposite way. The README says that if you are working on a high-quality project, or you want a one, two, or three letter domain, you should contact the administrators on the Discord server, where requests are manually reviewed to prevent squatting and to ensure they go to active projects.

This is the most defensible design decision in the repository and also the one that will frustrate you. A four character floor, enforced automatically, keeps the instant path genuinely instant. Pushing short names through humans keeps them from being claimed by speculators, which is the failure mode that killed most free subdomain services of this kind. The cost is that the fastest possible name to get is now the one you have to argue for in a chat channel, and the criteria for approval are described only as high quality and active.

The trade-off is worth naming because it inverts the usual ordering. With a paid registrar you pay for priority; here you trade money for review latency.

Governance claims and the limits of a sponsorship

The terms section is short and unusually specific about status. The README states that Intent is fiscally sponsored by Hack Club, a registered 501(c)(3) non-profit organization, and that this sponsorship provides the project's non-profit status and financial infrastructure. The top-level claim is that the service is free forever, carries no advertising, and is built for the community.

Free forever is the claim to hold most carefully. It rests on the sponsorship rather than on revenue from users, and the repository documents no mechanism by which a user's subdomain survives the end of that sponsorship. The terms do at least state the enforcement side clearly: phishing, malware and illegal content are prohibited, and the operators reserve the right to revoke subdomains that violate those terms to keep the network safe. So the risk profile is not that nobody will police the namespace, but that the namespace's continuation depends on an arrangement a user cannot inspect.

The last line of the README credits the project as built for the community. Activity, by contrast, is quiet: the last recorded push to this repository is 2026-03-15, which is more than six months ago. One open issue and 29 forks against a little over 2,100 stars is a shallow engagement surface. The service may well be running perfectly, but this repository gives no sign of ongoing work behind it, so its development status is best treated as unknown rather than current.

What this repository is actually good for

There is a legitimate use case here and it is narrower than the marketing suggests. A permanent-looking subdomain on a non-profit operated namespace, with no advertising and a published policy against abuse, is a decent fit for a student project, a hackathon entry, a personal site, or a tool that needs a stable hostname before it has any reputation of its own. The four character minimum makes names easy to say out loud, which matters more than it sounds for something people type from memory.

What the repository cannot tell you is anything about the operational behaviour. Whether records propagate fast, whether a claim survives a year, whether there is an API, whether there is email on these names, whether expired claims are reclaimed, and what the IFP Key gates all go unanswered here. A service that offers permanence without publishing a retention policy is asking for a level of trust that the documentation has not earned, and the prudent approach is to use one of these names for something where losing it would be inconvenient rather than fatal.

Judged as a repository, this one does its actual job. It is a clear, honest, short service page with the important negative information, the prohibited content list and the revocation policy all stated plainly. It is not, and does not pretend to be, a technical artifact you can inspect.

Editorial conclusion

There is no code here to evaluate, and pretending otherwise would be the wrong reading of this repository. What FreeDomain documents is a service with a real governance story behind it: a 501(c)(3) fiscal sponsorship, no advertising, a manual review path for the names most likely to be squatted, and a published list of prohibited content with an explicit revocation right. What it does not document is anything about how names are allocated, how records propagate, or what happens to your subdomain when the sponsorship ends, and those are the questions that decide whether a short subdomain is worth pointing a project at. If you want the operational detail, the WHOIS lookup and the dashboard will tell you more than this page does. Register something disposable first, watch how long the delegation takes, and only then move a real name onto it.

Frequently asked questions

Official sources

1. intentfreedomain/FreeDomain on GitHub
2. Issues
3. Project website
4. README