# is-a-good.dev: free subdomains handed out through pull requests > is-a-good.dev gives individual developers a free .dev subdomain, and the registration process is a pull request against a repository that holds the DNS configuration and the domain records. It suits people who want a personal site address without a registrar bill, and its rules are strict about what the subdomains may be used for. **is-a-good-dev/register** — Register for your is-a-good.dev domain! - Repository: https://github.com/is-a-good-dev/register - Website: https://is-a-good.dev - Stars: 632 · Forks: 734 - Language: JavaScript - License: GPL-3.0 - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/is-a-good-dev-register ## A domain registrar run as a git repository is-a-good.dev is described as a free subdomain provider for developers around the globe. The unusual thing about it is not the offering but the mechanism. The project is a repository, and a registration is a pull request against it. The repository layout makes the architecture clear. There is a dnsconfig.js file at the root, a domains/ directory that holds the individual domain records, and the .github/ directory for the workflow around them. A DNS zone for a whole set of subdomains is therefore a text file in a JavaScript configuration module, versioned like source code, with every change reviewed as a diff. The registration flow follows from that. The project documentation points to a separate documentation site, docs.is-a-good.dev, for registering a domain manually, and there is also a command line route: a CLI hosted in the is-a-good-dev/cli repository. So there are two ways in, one manual and one scripted, and both end in the same place, a reviewed change to the zone configuration. The people behind it are volunteers looking for help. A 2025 update in the project documentation asks for new helpers and maintainers, with a cover letter to a project address explaining why you want to help, and the top level entries include a LICENSE file and a README. The homepage is is-a-good.dev and there is a Discord server for the community. ## Your subdomain is a DNS record set in a pull request The submission rules are the part of the documentation that tells you how the system actually works, because the rejections are described as conditions on the pull request rather than as a separate policy document. A pull request will not be merged if the applicant already owns a subdomain on the service. One subdomain per person is enforced at review time, which is a simple mechanism for keeping the service finite. It will not be merged if the records provided include invalid or unpermitted record types. The project documentation says that in this case the maintainers will notify the applicant and request changes, so the process is a conversation rather than a silent rejection. It will not be merged if it violates user privacy, or if the domain is not being used for a valid personal website, blog or portfolio. That last condition is the significant one, and it is restated in a section marked IMPORTANT. Commercial and public projects are explicitly not a permitted use case, and the documentation underlines that subdomains are granted only for personal portfolios, websites and blogs. So the review is not a formality. A maintainer is checking that the record types are sensible, that the applicant is eligible, that no existing subdomain is being duplicated and that the use matches the terms. That is a human judgement on every request, and it is the reason the project also needs helpers and maintainers. ## Netlify is explicitly out of scope for now One exclusion has a technical explanation rather than a policy one. A pull request will not be merged if it uses Netlify, because there are issues with subdomain verification, and the project says it hopes to add support back soon. That is a good example of a rule that reveals a real constraint of the architecture. Verification of a subdomain normally happens by placing a record in the DNS zone and confirming a challenge token, and if a hosting provider's verification flow does not cooperate with a delegated subdomain, the check cannot complete. Rather than leave applicants guessing, the project writes the restriction into the merge criteria. The word soon in the documentation should be read with care. The project is volunteer run, and the gap is tied to a dependency outside its control, so the honest position is that Netlify based personal sites cannot currently be registered through this route, and that a hosting change later in the year may or may not land. For anyone choosing a host for a site on this service, the practical advice that follows from the documentation is to pick a host that is not on the exclusion list, or to plan on verifying the subdomain through a different method until support returns. ## Inactive subdomains get purged, with an email first The lifecycle policy is short and explicit. If your subdomain is inactive, it may be purged, and the project will try to notify you before purging via the email you provided when you registered. That single sentence carries the operational risk for users. There is no stated minimum activity level, no grace period length and no definition of inactive in the documentation available, so the practical reading is that a site you stop maintaining loses its name, with a notification as the only warning. For a personal blog that you revisit once a year, that is a live concern. The same email address has a second role, because it is also where maintainers send notifications about rejected records. It is therefore the single point of contact for the whole lifecycle, from application through rejection to expiry, and keeping it valid and monitored is the difference between learning about a purge in advance and finding out after the fact. The project also lists a Discord server as a place to watch, which is where a community-run service would communicate changes that are not in the repository. The documentation does not describe a formal notification process beyond the email, so anyone relying on this service should treat the Discord as the practical early warning channel rather than assuming the email alone covers every case. ## Sponsors cover the running costs, and the project wants more hands The service is free to users and the project acknowledges why it can stay that way. The documentation thanks the sponsors for keeping the project running, and the sponsor listed is BlueFoxHost, described as providing stable services while maintaining efficient customer service, offering Minecraft hosting, Discord Bot hosting and Terraria hosting at affordable prices. The sponsorship is also a good sign about the intent behind the service. The topics attached to the repository include developer-freebie, domain, free-for-developers, freedomain and freelance, which is a coherent picture of the audience: people who want an address for a personal site and would not otherwise pay for one. The corollary is that the service is subsidised rather than self-sustaining, and a subsidised service has a different risk profile from a paid one. A paid registrar has revenue at stake in keeping domains alive and resolving tickets. Here, the continuity depends on sponsors, on volunteer maintainers and on the willingness of the community to do the review work, which is exactly why the 2025 update asks for helpers and maintainers rather than merely announcing a feature. The project points to a similar projects listing, Free For Life, for other free domain offerings, which is a sensible way to compare how other operators handle the same trade-off. ## GPL-3.0 on a zone file, and what the repository does not tell you The repository is licensed GPL-3.0. For a repository whose main content is a DNS configuration and a set of domain records, that is a reasonable choice, since it makes the zone data reusable and forces anyone who redistributes a modified copy to keep the same terms. What the documentation does not cover is the questions that matter when you depend on someone else's subdomain. There is no statement about how to move a subdomain to a different DNS provider if the project changes its setup or winds down. There is no stated policy on whether you can delegate a subdomain further, for example to a hosting account that manages its own records. There is no published service level, and no account recovery procedure beyond the email notification. And the length of the inactivity grace period is unspecified. None of that is a reason to refuse the service. For a personal blog with a disposable URL, a free subdomain is a good deal. But the mismatch between the rules, which are precise about who may register and what they may do, and the operational details, which are absent, tells you where the risk sits. Eligibility is well policed. Durability is not. If the address matters to you, for a domain you intend to keep for years, the sensible route is to register a domain you own and treat is-a-good.dev as a learning environment, and if you do take a subdomain, keep the email address active, host the site somewhere that is not on the exclusion list, and check back on the Discord for any change to the purge policy. ## Conclusion Use is-a-good.dev for a personal portfolio, blog or site where a shared subdomain address is enough and you accept that the name stays on someone else's DNS. Do not use it for a commercial or public facing project, for a service other people depend on, or for anything you need to move to another host later without asking, because the project documents no export path. Before you request one, read the registration documentation at docs.is-a-good.dev, check that your intended use is personal and non-commercial, and be ready to keep the DNS records you submit valid, because a pull request with an unpermitted record type is rejected and requested back. ## FAQ ### How do I register an is-a-good.dev subdomain? The project documentation points to docs.is-a-good.dev for manual registration, and there is a separate command line tool in the is-a-good-dev/cli repository. Either way the registration becomes a pull request that adds your DNS records to the zone configuration held in this repository. ### What can I use an is-a-good.dev subdomain for? The documentation states that subdomains are only granted for personal portfolios, websites and blogs, and that commercial or public projects are not a permitted use case. A pull request for a domain that is not a valid personal site will not be merged. ### Why was my pull request rejected? The documented reasons are that you already own a subdomain, that the records include invalid or unpermitted record types, that it violates users privacy, that it uses Netlify because of subdomain verification issues, or that the domain is not for a valid personal website, blog or portfolio. For invalid record types the maintainers will notify you and request changes. ### What happens if I stop using my is-a-good.dev subdomain? If a subdomain is inactive it may be purged. The project says it will try to notify you before purging via the email address you provided when registering, so that address is the one to keep active and monitored. ## Sources - [is-a-good-dev/register on GitHub](https://github.com/is-a-good-dev/register) - [Issues](https://github.com/is-a-good-dev/register/issues) - [License: GPL-3.0](https://github.com/is-a-good-dev/register/blob/main/LICENSE) - [Project website](https://is-a-good.dev) - [README](https://github.com/is-a-good-dev/register/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/is-a-good-dev-register