# Your free web address

Source: https://modulify.ai/docs/publish/your-web-address

The modulify.website address every site is given, how to change it, and why it stays after you add a domain.

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.

You can see the current one in two 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 other place is the Domain tab itself, under the **Free Subdomain** heading, described as "Free subdomain from modulify. 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, private address that only loads inside the Modulify editor.

Unpublishing has the same effect in reverse. The **Unpublish** button in the Danger zone section of [Settings](/docs/editor/settings) takes the live address offline immediately, and it keeps returning nothing until you publish again. Your project, files, database and storage are untouched.

## The preview origin

While you build, the site runs at a private preview address that only loads inside the Modulify editor. 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 **Free Subdomain** 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.

### The storage warning

If your site has already been published and has files in Storage, saving a new subdomain opens a confirmation titled "Change your subdomain?". It explains that your storage files move to a new CDN address while the published site keeps requesting them from the old one until you publish again.

Take that seriously. Publish right after saving, or images and uploads on the live site will stop loading. When the site has never been published, or Storage is empty, the change saves with no confirmation.

## It keeps working after you connect a domain

Connecting a custom domain does not retire the free address. The site then answers on three hostnames: the free `.modulify.website` address, your root domain, and the www variant if you added one. All three 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 **Free Subdomain** 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. 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](/docs/publish/custom-domains) puts the site on an address you own.
- [DNS records](/docs/publish/dns-records) lists exactly what a custom domain needs.
- [Publish a site](/docs/publish/publish-a-site) covers the publish itself.