AI App Builder Custom Domain: From zugo.run to Your Own
Every Zugo project publishes free to a <slug>.zugo.run URL with one click — no card required. On paid plans (Pro, $25/month) you can connect a custom domain instead: add the domain in project settings, point a DNS record at Zugo, and your app serves from your own address. Free publishes carry a "Made with Zugo" badge; paid publishes don't.
That's the short version. The rest of this post covers what each option actually gives you, how DNS works if you've never touched it, and — honestly — when a custom domain is worth paying for and when it isn't.
How does publishing work on Zugo?
You describe what you want in plain language — "a booking page for my dog-grooming studio in Austin with a price list and a contact form" — and Zugo assembles a working site or app. Simple builds arrive in about a minute; multi-page platforms with a database, auth, or payments take a few minutes and show checkpoints plus a live process log while they build.
Before you ever see the result, it's verified in a sandbox. "Verified" means something specific here: the build actually loaded and rendered. You're not publishing code that might be broken — you're publishing something that already ran.
Publishing itself is one click. Zugo picks a slug from your project name (you can change it), and the app goes live at <slug>.zugo.run immediately. If you're shipping a game rather than an app, the flow is identical — we covered that end to end in how to publish a game online for free.
What do you get on the free zugo.run URL?
A real, shareable, live URL — instantly. For a lot of projects that's genuinely all you need:
- Prototypes. You built something in a minute; you want feedback in two. Send the link.
- Playtests. Games live on a URL friends can open on their phones, no install.
- Portfolio pieces. A working demo beats a screenshot in any job application.
- Validating an idea. Before buying
myidea.com, find out whether anyone clicks.
The trade-offs are equally real, and worth stating plainly. The address advertises where it was built. Free publishes show a "Made with Zugo" badge. And any SEO authority the page earns accrues to a subdomain of zugo.run, not to a domain you own — if you later move the project, links pointing at the old URL don't move with it.
None of that matters for a weekend prototype. All of it matters for a business.
How do custom domains work on paid plans?
Custom domains are included in Pro at $25/month — the same plan that gives you 200 credits, which is roughly 16 full platforms or 33 quick builds a month. Business at $99/month includes them too. The domain itself comes from a registrar (Namecheap, Cloudflare, Porkbun, GoDaddy — any of them), typically $10–15/year for a .com.
The connection flow has three steps:
- Add the domain in your project's settings. Zugo shows you exactly which DNS records to create.
- Create those records at your registrar. This is a copy-paste job in the registrar's DNS panel — usually one record for the root domain and one for
www. - Wait for DNS to propagate. Often minutes, occasionally a few hours. Zugo picks up the change and starts serving your app from the new address, with the certificate handled for you — nothing to buy or install.
Your build, your data, and your connectors (Supabase, Stripe, Google Analytics, Resend) don't change. Only the address does.
DNS basics: what are you actually configuring?
DNS is a phone book. When someone types pawsofaustin.com, their browser asks the DNS system "what server answers for this name?" — and the records you created are the answer. Two record types cover almost every case:
| Record type | What it does | Typical use |
|---|---|---|
| A record | Points a name directly at a server's IP address | The root domain (pawsofaustin.com) |
| CNAME record | Points a name at another name, which resolves from there | Subdomains (www.pawsofaustin.com, app.pawsofaustin.com) |
Two more terms you'll see in the registrar panel:
- TTL (time to live) — how long the internet caches your record before re-checking. Lower TTL means changes show up faster; the default is fine.
- Propagation — the lag while caches around the world pick up your new records. This is why a freshly connected domain can work on your phone before it works on your laptop. It resolves on its own.
That's the whole vocabulary. You don't need to understand nameservers, zones, or anything deeper to connect a domain — you're copying two records from one panel into another.
Free subdomain vs custom domain: which one, when?
Free: <slug>.zugo.run |
Custom domain (Pro/Business) | |
|---|---|---|
| Cost | $0, no card required | $25/mo (Pro) + ~$10–15/yr for the domain |
| Setup | One click, live in seconds | One click + two DNS records, live in minutes–hours |
| Badge | "Made with Zugo" | None |
| Address | dog-grooming-austin.zugo.run |
pawsofaustin.com |
| SEO authority | Accrues to the zugo.run subdomain | Accrues to a domain you own and keep |
| Portability | Links break if you move the project | Repoint DNS anywhere; links survive |
| Best for | Prototypes, playtests, demos, validation | Anything you'll market, sell, or run ads to |
When does a custom domain actually matter?
For SEO — as soon as you want to rank. Search engines assign authority to domains. Every backlink, every mention, every indexed page compounds on whatever domain hosts the content. On a free subdomain, that compounding benefits an address you don't own. On your own domain it's an asset: if you ever migrate hosting — say you export the project to GitHub and redeploy through the Vercel connector to your own account — you repoint DNS and keep every link you've earned.
For ads and email — immediately. Ad platforms review destination URLs, and a branded domain converts better than a builder subdomain in ad copy. Email is stricter still: sending from a domain you own, with Resend wired up as your email connector, is table stakes for deliverability.
For trust — the moment money is involved. If Stripe checkout is in the flow, users will glance at the address bar. pawsofaustin.com reads as a business. A builder subdomain reads as a test.
When it doesn't matter: hackathon entries, game-jam builds, internal tools, anything with a lifespan measured in weeks. Spending $25/month to put a domain on a throwaway prototype is the wrong order of operations — validate first on the free URL, upgrade when the project earns it.
A realistic path from prototype to domain
A sequence we see often, in practice:
- Prompt: "Make a landing page for a meal-prep service in Denver — hero, three pricing tiers, FAQ, and an email signup form." Build verifies and renders in about a minute. (If you're starting from zero, making a website with AI walks through this step by step.)
- Publish free to
denver-meal-prep.zugo.run. Share it in two local Facebook groups. - Forty signups later, buy
prepdenver.com, upgrade to Pro, add two DNS records. - Same build, same form, same analytics — new address. Start running ads.
Nothing was rebuilt between step 2 and step 4. That's the point of separating publishing from the domain: the free URL is for finding out whether the idea works, and the custom domain is for the moment you know it does.
Browse what people have shipped — free URLs and custom domains alike — on the showcase.