Stackryze FreeDomains: four free subdomains and the Vite frontend that claims them

The repository holds a Vite frontend that expects an API on port 5000

Everything that registers, edits or deletes a name lives behind an HTTP API that is not in this repository. The top level of the checkout is a JavaScript app: index.html, src/, public/, vite.config.js, eslint.config.js, wrangler.toml and package.json, whose name is @indevs/frontend at version 0.1.0 and marked private so it never reaches a registry. No server, database or zone file sits anywhere in the tree. The only hint at where records are written is the VITE_API_URL entry in .env.example, which points at http://localhost:5000, a process this project never starts. The practical effect: running npm run dev gives you the interface, and every claim or edit button inside it fails because nothing answers on port 5000. Self-hosting this code does not get you a domain.

Two bot check vendors are wired in, but only one key is documented

The dependency list carries @hcaptcha/react-hcaptcha at ^1.17.1 and @marsidev/react-turnstile at ^1.4.1, so the claim flow can be guarded by two different anti-automation vendors in one form. The example environment file defines only one of them:

VITE_API_URL=http://localhost:5000
VITE_TURNSTILE_SITE_KEY=

No hCaptcha site key variable appears anywhere in that file, and nothing in the project states where an hCaptcha key is supposed to come from. What that means for you: leave VITE_TURNSTILE_SITE_KEY empty and the widget has no key to validate against, and the hCaptcha path has no configured value at all. Stand up your own copy of this interface and you have to obtain both keys from the service operator before a single submission can go through.

Records resolve from a single primary in New York

The namespace is served by three hostnames with three different roles. ns1.stackryze.com is the primary server in New York City. ns2.stackryze.com is a secondary in Nuremberg, and ns3.stackryze.com is a secondary in Hyderabad. A secondary holds copies of what the primary hands it, which makes the distribution real but not the write path redundant. Every record change, including each edit you make to point a claimed name at your own infrastructure, runs through one host in one city. No fourth name server, no anycast address and no failover procedure appear in the repository. When something misbehaves, the only place this project points you is status.stackryze.com for incident updates, with [email protected] as the mail route.

The four extensions live under a namespace Stackryze publishes

The available list is .indevs.in, .sryze.cc, .ryzedns.org and .nx.kg, followed by a note that more extensions are coming soon. Each of those sits on a second-level namespace for which Stackryze publishes the records, so what you receive is a label inside someone else's zone rather than a registration you hold. The promise of full ownership and complete control applies to the record data you edit, not to the parent zone, and the two are not the same thing. What the project leaves uncovered is mail: no MX record, mail host or mail policy is named anywhere, so a plan built on free domains for email has nothing to lean on here. And because the extension list is explicitly still growing, the set you depend on now is not a fixed set.

The two documented deploy paths target different platforms

There are several ways to ship this app and they do not all aim at the same place. The npm script targets a Cloudflare Workers deployment, and the cleanup before that push is baked into the script itself:

"dev": "vite",
"build": "vite build",
"lint": "eslint .",
"preview": "vite preview",
"deploy": "rm -rf .wrangler/deploy && npx wrangler deploy

The comment in .env.example instead says to set VITE_API_URL and VITE_TURNSTILE_SITE_KEY as build-time variables in Cloudflare Pages project settings, while wrangler.toml governs the Workers route, and the Dockerfile gives you a third option with no cloud dependency at all. The cost of that ambiguity is a wasted deploy cycle. Decide which platform your account actually has before you start wiring environment variables, because the same dist output lands in different places depending on which path you take.

The container build forces legacy peer dependency resolution

The Dockerfile sets an install flag before it installs anything, and passes the API endpoint in as a build argument:

ENV NPM_CONFIG_LEGACY_PEER_DEPS=true
RUN npm ci
ARG VITE_API_URL
ENV VITE_API_URL=$VITE_API_URL
RUN npm run build

The graph is wide: a dozen-plus @radix-ui packages at ^1.x and ^2.x alongside @hookform/resolvers at ^5.2.2, all resolved as ES modules under type: module. A fresh npm ci outside the container does not carry the flag the image depends on, so export the same variable yourself rather than guessing at version pins. The runtime stage is thinner still: it installs serve globally and runs a static file server on port 3000, not a Node application server.

No releases, no published package, and no renewal terms

package.json is private at version 0.1.0 and the repository publishes no GitHub releases, so there is no tagged artifact to pin and npm install @indevs/frontend is not a path anyone can take. Nothing here states how long a claimed name lasts, how many a person may hold, or what happens when one is released back. The README does not document a rollback path, a programmatic claim API, or rate limits, and the sponsors block renders as an empty row with no named organization behind it. The only channels offered are the GitHub issue tracker, a Discord invite, [email protected] and [email protected]. Plan around that: keep your records at a DNS provider you control, so moving away is a delegation change rather than a negotiation.

Editorial conclusion

It suits a class project, a demo or an open-source site where a free subdomain is enough and you can accept that the parent zone belongs to Stackryze. Skip it for anything needing mail, a durable brand, or a name you renew on your own terms. Before committing, check the status page, confirm your extension still shows in the dashboard, and remember this repository will not hand you the service itself.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository