Your own domain, without a website builder (2026)

You have the file. Maybe Claude generated a one-page site from a paragraph of brief. Maybe Cursor wrote a landing page, or a designer handed you a self-contained build. It opens correctly in a browser. The content is finished. The only thing missing is that the URL says someone else's name, or a long random string, instead of yours.

The instinct is to reach for a website builder. But look closely at what a builder actually asks of you: before it gives you a custom domain, it wants you to rebuild the page inside its editor — drag its blocks, fill its fields, match its theme. You'd be reconstructing a page that already exists, in a tool whose whole reason to exist is the editing you don't need to do. The domain is bundled with a rebuild you didn't ask for.

The thing you're actually trying to do

Separate two jobs that builders fuse together:

1. Make the page. Already done. The HTML exists and renders.
2. Put it at your domain. This is a hosting-and-DNS job, not an authoring job.

A website builder is good at job one and charges you for it whether you need it or not. When the page is finished, you only have job two left — and job two is small. It's a file sitting at a URL, and a DNS record telling yourname.com to point at that URL. Nothing about that requires an editor.

This is the difference between hosting a finished build behind a link and signing up for a platform that wants to own the page. One treats your file as the finished product. The other treats your file as raw material for its own canvas.

Why "I already have the file" changes the math

Most domain-and-hosting advice assumes you're starting from nothing — pick a platform, learn its editor, build, publish. That advice is sized wrong for your situation. You're not building. You're delivering something built.

When the page is done, the questions shrink:

• Does the host serve a single self-contained HTML file as-is, without converting it into its own format? (You want the bytes you uploaded, not a re-rendered approximation.)
• Can you put your domain on it without re-authoring?
• When you change the page later, do you edit the HTML and re-upload — or do you have to log into an editor and recreate the edit by hand? (Editing the file yourself needs nothing installed; an editor in the browser will do, and the file stays on your machine.)

A private-link host answers all three the way you want: it takes the file, gives you a link, and lets a custom domain sit in front of that link. The page that loads is the page you made. Updating it is dropping a new file at the same spot.

The walkthrough, end to end

Starting from "I have a finished HTML file":

1. Drop the file. Upload the single HTML — all CSS and JavaScript inlined, images embedded or linked — to a private-link host. You get an unguessable link back immediately. The page is live, just not at your domain yet. (Anonymous uploads cap at 3MB and the link runs for 7 days; a free account keeps the link from self-destructing on a Solo plan, where links never expire.)

2. Check it renders. Open the link on your phone. The whole point of a self-contained file is that it carries everything it needs, so what you see is what your visitors see. If your export left assets pointing elsewhere, inlining CSS and JavaScript into the file covers what "inline everything" means in practice.

3. Add the DNS record. In your domain registrar, add one CNAME from a subdomain — site.yourname.com, hello.yourname.com — to the host's address. A dedicated subdomain is cleaner than your apex domain, which usually serves your main site. The custom-domain setup walkthrough has the DNS detail and the gotchas (propagation lag, leftover AAAA records, the Cloudflare proxy toggle).

4. Verify and let SSL provision. Click verify in the host's dashboard. It checks the record and issues an SSL certificate automatically, usually inside ten minutes. Now site.yourname.com serves your file with the padlock. (Custom domain is a Studio feature, $14.99/mo.)

5. Decide who can find it. Private-link hosts default to no-index — the page is private delivery, reachable by anyone you send the link to, not surfaced to the public web. If you want this page findable in search (a portfolio, a public profile), flip the per-page searchable opt-in. If it's a deliverable for specific people, leave it private.

Total work: one upload, one DNS record, one toggle. No editor, no rebuild, no theme to wrestle.

What this is good for — and the one case it isn't

This pattern fits any finished, static page you want at your own URL: a portfolio or CV on your own domain, a portfolio served as a private link, a landing page an AI tool wrote, a one-pager you'd otherwise send as a link instead of an attachment. The common thread: the page is done, it's self-contained, and it doesn't need a server thinking on its behalf.

Here's the honest boundary. "Static" means the page runs entirely in the visitor's browser — HTML, CSS, client-side JavaScript. The moment your page needs a real backend — a database it reads from, server-side code, a login system, an API that signs requests with a secret — putting it on a file host won't work, because there's no server to run that logic. That's a different tool. Vercel and Netlify are built for exactly that job: they run your server-side code, give you a custom domain, and handle the database wiring. If your "page" is really an app with a backend, deploy it there. A private-link host owns the static slice — the finished front-end file that just needs a home at your domain.

Most single pages people want at their own domain are static. A portfolio doesn't query a database. An exported document doesn't run server code. A generated landing page is usually client-side only. For those — the large majority — the file you already have plus one DNS record is the whole job, and a website builder was never the right shape for it.

The update story

The part that decides whether this sticks is what happens next month. With a builder, an edit means logging in, finding the page, navigating the editor, republishing. With a file at your domain, an edit means: change the HTML (or re-export from wherever it came from), drop the new file at the same link, done. The domain doesn't move. The visitor's URL doesn't change. You skipped the editor entirely — the same reason you skipped it the first time.

You had a finished page. Now it lives at your name. Nothing in between asked you to build it again.