Your free web address

Every site project is given a free web address the moment it is created. It looks like my-site.modulify.website, it costs nothing on any plan, and it is the address your published site answers on until you connect a domain of your own.

The shape of the address

The address is one subdomain label followed by .modulify.website. The label starts life as a generated three part slug, something like violet-pixel-47e, so no two projects ever collide on their first day. The first build renames it to match the project name chat picks, so a site named Lisbon Pottery Studio ends up at lisbon-pottery-studio. When that exact name is already taken, chat adds a short suffix such as -k13 rather than leaving the generated slug in place.

You can see the current one in three places. The publish popover, opened from the Publish button in the top right of the editor, has a Subdomain row showing the host. When the site has been published, an arrow button next to it opens the live site in a new tab, and the pencil button jumps straight to the Domain tab.

The second is the strip above the preview frame, which shows the full address next to a Connect domain button. It appears once the site is published, and only for the owner of a Free workspace, while the site has no custom domain yet or its custom domains are paused. See Use the preview.

The third is the Domain tab itself, under the Site Address heading, described as "The identifier used in your project URL, and your free modulify subdomain. Change it anytime. Takes effect immediately if an initial publish exists."

It only serves after a publish

The address exists from creation, but nothing answers on it until the first publish. The preview you work in is a separate address that only loads inside Modulify, so it is no use handing it out. To show someone the preview before you publish, share a read-only link instead.

Unpublishing has the same effect in reverse. The Unpublish button in the Danger zone section of Settings takes the live address offline immediately, and it keeps returning nothing until you publish again. Your project, files, database and storage are untouched. Chat can do this for you too when you ask, after you confirm.

Archiving a project does not unpublish it. A published project stays live in the Archive, unless you tick Also unpublish this site when you archive it. See Archive projects.

The preview origin

While you build, the site runs at a preview address that only loads inside Modulify, in the editor or for someone viewing its read-only link. Some third party services need to know that address before they will talk to it: an OAuth provider that only redirects back to hosts on its allowlist, or an API that checks where a request came from.

The Domain tab carries a Preview origin row at the bottom for exactly that. It reads "Add this origin to external services (APIs, OAuth) to accept requests from your preview. Only loads inside Modulify, spins down when idle." The field is read only, marked with a padlock, and has a copy button on the right.

Copy the value and paste it into whichever allowlist the service keeps. Add it alongside your live address rather than instead of it: the preview and the published site are different hosts, and a service that only trusts one of them will fail on the other.

Two things to watch:

• The value is the hostname on its own, with no https:// in front and no query string after it. A service that wants a full origin needs the scheme adding back.
• The preview spins down when it is idle. Until it is running the row falls back to Modulify's base preview domain rather than your project's own host, so open the Preview tab and let it start before you copy anything.

Changing the subdomain

Open the project, click More in the tab strip, then Domain. The address is /dashboard/projects/<project>/domain. Edit the Site Address field and click Save.

Changing it needs the Manage domains permission, which the workspace owner always has and which a custom role can be given. Members without it see the field and the button disabled.

What the field accepts

The input lowercases whatever you type. The value has to satisfy all of these, and the field tells you which one you broke.

Rule	Message when you break it
At least 3 characters	Subdomain needs to be at least 3 characters!
At most 63 characters	Subdomain can not have more than 63 characters!
Lowercase letters, numbers and single hyphens between them, never at either end	Subdomain must contain only lowercase letters, numbers, and hyphens!
Not one of the reserved words	That subdomain is reserved and cannot be used!

The reserved list holds just over 100 names that would be confusing or dangerous as a public host, including www, api, app, admin, mail, cdn, preview, staging, dashboard, login, billing, support, docs, blog, status and modulify.

Availability

As you type, Modulify checks the name against every other project. A spinner sits in the field while it checks, then either a green Subdomain is available. appears or the field reports That subdomain is already taken!. The Save button stays disabled until the value is valid, available and actually different from the current one.

Names are unique across all of Modulify, and deleted projects still hold theirs, so a name being taken does not mean it is in use on a live site.

Publish again after a change

Your site's CDN address is built from its subdomain, so a new subdomain moves the CDN address too, and the old one stops working. The published site does not follow on its own: it keeps the addresses it was published with until you publish again.

If your site has already been published, saving a new subdomain opens a confirmation titled "Change your subdomain?". It reads "Your CDN address moves with the subdomain, and the old one stops working. Publish again after saving so your live site keeps loading storage files, sending email and calling the analytics API. Files linked by their full CDN address in pages or stored content must be updated to the new address, because a publish alone does not change them."

Take that seriously. Publish again after saving, or storage files, email sending and analytics API calls on the live site can stop working. When the site has never been published, the change saves with no confirmation.

A publish hands the live site its current addresses, but it never rewrites an address written out in full. A file linked by its full CDN address in a page, or saved in stored content such as a database row or a JSON file in Storage, keeps pointing at the old address and stops loading until you update it to the new one. That is true even for a site that was never published, since the old address stops working either way. Chat can replace the old address in the site's code for you.

Ask chat

You can also ask the site chat to change it, in plain words such as "change the subdomain to lisbon-pottery-studio". The same field rules and availability check apply. Chat does not open the confirmation, but the same rule applies: a published site needs publishing again afterwards, or its storage files, email sending and analytics API calls can stop working. Right after the change, chat also looks for the old CDN address in the site's code and replaces it with the new one, and reminds you that a full CDN address saved in stored content has to be updated too, because a publish alone does not change it. When the exact name is already taken, chat adds a short suffix such as -k13 instead of failing, and the editor URL updates on its own, so the page you are on keeps working.

It keeps working after you connect a domain

Connecting custom domains does not retire the free address. The site then answers on the free .modulify.website address, on every custom domain you connected, and on each one's www variant if you added it. All of them serve the same pages from the same deployment.

That is fine for visitors and awkward for search engines, which see the same content at more than one address. If you want a single canonical address, the Site Address row grows a hint once a custom domain is connected: "Want one address instead of two? Ask the AI to redirect this free subdomain to your custom domain, so visitors always land on the same address. The change goes live on your next publish."

Its Ask AI button opens chat with the request already written, naming both hostnames and the direction. With several domains, the request redirects to your primary domain. The redirect is a code change compiled into the build, so it goes live on your next publish, not immediately.

One thing to remember afterwards: renaming the free subdomain later leaves that redirect pointing at the old host, so the rule has to be updated too.

Next

• Connect a custom domain puts the site on an address you own.
• DNS records lists exactly what a custom domain needs.
• Publish a site covers the publish itself.