# is-a.bot: A Free Subdomain Service for Robot Websites, Forked from is-a.dev > is-a.bot gives developers a free .is-a.bot subdomain for their robot's website, using the same registration flow as is-a.dev but with its own repository and limitations, including no URL records and known Vercel verification issues. **free-domains/is-a.bot** — Grab your own sweet-looking '.is-a.bot' subdomain. - Repository: https://github.com/free-domains/is-a.bot - Website: https://is-a.bot - Stars: 166 · Forks: 488 - Language: JavaScript - License: MIT - Published: 2026-08-24 · Updated: 2026-08-24 · Language: en - Canonical page: https://hysenlabs.com/projects/free-domains-is-a-bot ## The Problem: A Subdomain That Says 'Bot' Without Owning a Domain is-a.bot solves a narrow but real problem: developers who build robots, bots, or automated services often want a web presence that signals what the project is. Buying a custom domain like mybot.com costs money and requires DNS management. A free subdomain under .is-a.bot gives a project an address that is short, descriptive, and tied to the bot identity. The service is aimed at developers who already know how to use GitHub pull requests and DNS records. It is not for non-technical users or for projects that need a branded, top-level domain. The README is clear that the registration process mirrors is-a.dev, so the target audience is the same: developers comfortable with forking repositories and editing configuration files. ## How Registration Works: Fork, Edit, Pull Request The mechanism is a pull-request-based DNS registry. To get a subdomain, you fork the repository, follow the instructions on the documentation site at docs.is-a.dev, and open a pull request. A reviewer checks your request. If changes are requested, you must make them, or the README warns you will be rejected. Once the PR is merged, DNS records are published within a few minutes. This design means the service does not run a web form or an API for registration. Instead, the repository itself is the control plane. The actual DNS records are stored in the repository, likely as JSON or YAML files, though the README does not show the exact format. The documentation at docs.is-a.dev would have that detail, but the README only points to it. The process is transparent and auditable, since every change goes through a public pull request. But it also means you need a GitHub account and familiarity with the fork-PR workflow. ## Getting Started: Commands and Config You Actually Need The README does not include a single command or a config file example. It only gives three steps: fork, follow the docs, and open a PR. The documentation at docs.is-a.dev is the authoritative source for the record format, but the README does not reproduce it. Based on the is-a.dev pattern, you would likely create a JSON file in a subdirectory named after your subdomain, with fields for the owner and the DNS records. But that is an inference, not a fact from the material. The only concrete detail is that URL records are not offered, which means you cannot create a redirect like subdomain.is-a.bot to another URL. You can only set DNS records such as A, AAAA, CNAME, or TXT, depending on what the docs specify. The registration process itself is the same as is-a.dev, so if you have registered there before, you already know the steps. For a new user, the first action is to visit docs.is-a.dev before forking, because the README gives no inline instructions. ## Limitations: No URL Records and Vercel Verification Problems The README states two explicit limitations. First, is-a.bot does not offer URL records, unlike is-a.dev. That means you cannot set up a simple redirect from your subdomain to another site. You need a real DNS record that points to an IP or a hostname. This is a significant constraint if your bot's site is hosted on a platform that requires a CNAME or an A record, but not if you wanted a vanity redirect. Second, the README acknowledges known issues with verifying subdomains on Vercel. It says the maintainers are sorting this out ASAP, but it does not give a timeline or a workaround. If you host on Vercel, you may not be able to verify the domain in the Vercel dashboard, which could block deployment or HTTPS. This is a real failure mode for a common hosting choice. The lack of a verification workaround in the README means you should test this before relying on the subdomain for production traffic. ## The Wrong Tool: When is-a.bot Does Not Fit is-a.bot is the wrong tool if you need a custom domain for a non-bot project. The .is-a.bot TLD is specific to robots, so a personal blog or a company site would look misplaced. It is also wrong if you need URL redirects, since they are not supported. If you need to move a domain between hosting providers frequently, the pull-request process is slow compared to a DNS control panel. Each change requires a PR, review, and merge, which could take hours or days depending on maintainer availability. For a project that needs rapid DNS changes, this is a bottleneck. Also, if you cannot use GitHub or do not want to manage a fork, this service is not for you. The entire registration flow depends on GitHub collaboration. The README does not mention any alternative registration method, so it is the only path. ## Alternative: is-a.dev and the Difference in Approach The natural alternative is is-a.dev, the service that owns and operates is-a.bot. The README says is-a.bot uses the same registration process but a different repository. The key difference is the domain namespace: is-a.dev gives you a .is-a.dev subdomain, which is generic and not tied to bots. is-a.bot is specifically for robot websites. Another difference is that is-a.dev offers URL records, while is-a.bot does not. That is a concrete functional gap. If you need a redirect, is-a.dev is the better choice. If you want a subdomain that explicitly says 'bot', is-a.bot is more fitting. Both use the same PR-based mechanism, so the workflow is identical. The choice comes down to the namespace and the URL record support. There is no other alternative mentioned in the README, so this is the only direct comparison available. ## Maintenance and License: What You Inherit The repository is licensed under MIT, which means the code that powers the registry is open for reuse. The README does not describe the internal scripts or how the DNS is published, so the maintenance burden is unclear. However, because the service is operated by the is-a.dev maintainers, you are relying on their uptime and responsiveness. The README mentions that issues with Vercel verification are being sorted out, which implies active maintenance. But there are no release notes or recent release information in the material, so you cannot confirm how frequently updates happen. For a user, the maintenance cost is low: you only need to update your DNS record if your hosting IP changes, which again requires a PR. The license does not affect you as a user, since you are not running the code. You are just using the DNS service. The main risk is that the service could be discontinued, but the README does not indicate any such plan. ## Conclusion Adopt is-a.bot if you run a robot or bot project and want a free, recognizable .is-a.bot subdomain without managing your own DNS infrastructure. Avoid it if you need URL redirect records or rely on Vercel for hosting, since the README admits verification issues with Vercel and does not offer URL records. Before adopting, verify the current documentation at docs.is-a.dev for the exact DNS record format and check the repository's recent activity for any changes to the registration process or known issues. ## FAQ ### What is the is-a.bot service? It is a service that gives developers a subdomain under the is-a.bot domain for a robot's website, owned and operated by the maintainers of the is-a.dev service. Registration works the same way as that service, except that the pull request is made against this repository rather than the other one. ### How do I register a subdomain with is-a.bot? Fork the repository, follow the instructions in the separate documentation, and open a pull request. The request is reviewed, and if changes are requested the readme says you will be rejected unless you make them. Once the pull request is merged, your DNS records are published within a few minutes. ### Does is-a.bot offer URL records? No. The readme states explicitly that URL records are not offered, unlike the is-a.dev service, and that the terms of service the abuse process refers to are hosted on that other domain rather than here. ### How is the is-a.bot DNS zone maintained? Inside the repository: a DNS configuration script at the root, a directory of domains, a utility directory and a test directory. The manifest has one script, a test run through npx over the test files, and two development dependencies, a test runner and a filesystem helper, with no build or publish step. ## Sources - [Official documentation](https://is-a.bot) - [Official README](https://github.com/free-domains/is-a.bot#readme) - [Project repository](https://github.com/free-domains/is-a.bot) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/free-domains-is-a-bot