Bind a Custom Domain

Custom domains are one of the places where Flash Launch is most useful. This is where many launches become operationally messy: DNS, HTTPS, certificate timing, and the question of whether the site is really live yet.

The current Flash Launch MVP turns that into a guided flow:

1. enter a hostname
2. add a TXT record that proves ownership
3. add an A record that points traffic to Flash Launch
4. wait for DNS to point correctly
5. let the platform keep checking for HTTPS readiness
6. switch to active once the certificate path is usable

If you want the broader product context first, read What Flash Launch Is.

What this feature does today

In the current MVP, Flash Launch supports a semi-automated custom domain binding flow built on a shared load balancer path.

That means:

• you choose the hostname
• Flash Launch validates and stores it
• Flash Launch tells you exactly which TXT and A records to add
• Flash Launch checks DNS and HTTPS status for you
• Flash Launch keeps track of the domain state in the project console

The feature is real and usable today, but it is important to understand the current shape of the system: this is not yet a fully automatic "we configure every network resource for you" domain product.

What kind of hostname to enter

When binding a domain in the current product, enter only a hostname.

Good examples:

• app.example.com
• www.mysite.com
• docs.product.io

Do not enter:

• https://app.example.com
• http://app.example.com
• app.example.com/path

The platform validates the hostname format and rejects invalid shapes. The expected input is a plain hostname with no protocol and no path.

The current MVP boundary

There are two important product constraints to know up front.

So if a project is already bound to one hostname, the platform will not silently replace it with another. That is intentional. Ownership boundaries around production domains should be explicit.

How the current domain flow works

The current flow has four practical stages.

1. Bind the hostname

In the project console, go to Domain + HTTPS, enter your hostname, and click Bind Domain.

At that point Flash Launch:

• normalizes the hostname
• checks whether it is already bound elsewhere
• stores the domain on the project
• generates DNS instructions
• creates a background job to start checking readiness

This is the point where the platform starts acting as the control plane for the domain.

2. Add the TXT ownership record

After binding, the UI first shows a TXT record under _flashlaunch.<hostname>. Add this at your registrar or DNS provider so Flash Launch can confirm that you control the hostname before public routing is enabled.

3. Add the A routing record

After ownership is verified, the UI asks you to point the hostname at the shared load balancer IP.

This is why the current flow is called semi-auto: Flash Launch manages the state model and verification flow, but you still make the DNS change in your own DNS console.

What status values mean

The domain panel exposes the launch process as states instead of hiding it behind a spinner.

This matters because domain problems are rarely binary. A domain can exist in the system long before it is safe for browsers to trust it. Flash Launch models those intermediate states instead of pretending the process is instant.

What to do during `pending_ownership`

If the status is pending_ownership, Flash Launch has not seen the TXT challenge record yet.

At this stage:

• confirm you added the exact TXT record name and value shown in the UI
• make sure the record is under the hostname you are binding
• wait for DNS propagation
• click Check status

What to do during `pending_dns`

If the status is pending_dns, the most likely explanation is simple: the hostname is not yet resolving to the expected shared load balancer IP.

At this stage:

• confirm you added the exact A record shown in the UI
• make sure you edited the correct hostname
• wait for DNS propagation
• click Check status

The current platform messaging is intentionally direct here: configure the DNS A record, wait for propagation, then check again.

What to do during `verifying`

If the status moves to verifying, that is progress. It means DNS is already correct and the system is now waiting for HTTPS readiness.

In the current MVP, Flash Launch probes https://your-hostname/ to determine whether the certificate path is usable yet.

What this means for you:

• your DNS step is probably complete
• HTTPS is not yet fully ready
• the right next action is usually patience plus Check status

The UI treats this as a separate stage because DNS success and HTTPS success are not the same event.

What `Check status` actually does

The Check status button is not a cosmetic refresh.

In the current implementation it:

• re-checks the current hostname
• updates the project domain state
• may create a follow-up background job if the domain is still not active

This is useful because domain activation often takes multiple rounds:

• one round for DNS to become authoritative
• another for certificate systems to see the domain correctly
• sometimes another for HTTPS probes to pass cleanly

So if the domain is not active yet, Flash Launch does not simply stop. It continues to represent the work as a background job and a domain state transition.

What kinds of errors you should expect

The current domain flow is designed to surface actionable errors instead of low-level platform noise.

Typical problems include:

• the hostname points to the wrong IP
• DNS propagation is incomplete
• HTTPS probe is still failing even though DNS is fixed
• the hostname is already bound to another project
• the project already has a different hostname attached

When possible, the platform pairs the error with a next-step hint. This is part of the product philosophy: if a user hits an operational problem, the UI should help them resolve it, not just label it.

A practical checklist before binding

Before you bind a custom domain, confirm these points:

• you control the DNS for the hostname you want to use
• you know exactly which subdomain you are binding
• the project is the correct destination for that hostname
• you are prepared to add a TXT ownership record at your DNS provider
• you are prepared to add an A record at your DNS provider
• you understand that HTTPS may take longer than the DNS change itself

This checklist matters because domain mistakes are often ownership mistakes rather than technical mistakes.

What this feature is best for right now

The current custom domain flow is best when you want:

• your static site or project landing page reachable on your own hostname
• a clearer state model than editing DNS and guessing
• HTTPS readiness surfaced as a product concern, not hidden infrastructure work
• a single place to see domain state and retry checks

It is especially useful for builders who want the professionalism of a real branded domain without manually stitching together every verification step themselves.

Current limitations to understand

This is the honest version of the feature, not the aspirational version.

• The current path is semi_auto, not fully automatic infrastructure orchestration
• The shared load balancer IP must already exist in platform configuration
• The current MVP supports one hostname per project
• Fully automated auto mode is not yet implemented
• Domain activation can still take real-world time because DNS and certificate systems are external to your local action

These limitations are normal for the stage of the product. What matters is that the system already turns domain binding into a trackable, understandable workflow rather than an undocumented cloud chore.

The right mental model

Flash Launch does not make DNS disappear. It makes DNS manageable.

That is the right way to think about this feature.

You still own your hostname. You still make the registrar change. But Flash Launch:

• validates the destination
• verifies hostname ownership
• provides the exact DNS target
• tracks the status transition
• checks HTTPS readiness
• keeps retrying while the domain is not yet live

That is the product value: less hidden infrastructure uncertainty between "I want this on my domain" and "the browser now trusts it."

Related docs

• What Flash Launch Is
• Deploy a Static Site
• Publishing Fundamentals Handbook