Lovable custom domain: connect and check your app

Before connecting a custom domain to a Lovable app, confirm that its current publishing controls support the connection you need and provide the required DNS values. Lovable’s overview↗ (opens in a new tab) documents web app publishing, but does not establish exact custom-domain controls or required records. The steps below are general preparation and verification checks to use after confirming the instructions for your app. Keep the chosen address and unresolved checks in fenbs so another person or AI can continue without repeating the investigation.

Treat connecting the address as its own task with its own evidence. A working preview, a published app, and a working custom address answer different questions; check each part before sharing the address with customers. If the current publishing controls do not confirm the connection requirements, get those instructions before changing DNS.

What should you prepare before changing anything?

Write down the exact address you want people to use. A bare domain such as example.com, www.example.com, and app.example.com are separate hostnames. Choose which is your main address and which additional addresses you intend to test. A simple written choice prevents two people from configuring different destinations.

• Identify the Lovable app you intend to publish, using its name and current live address.
• Confirm that you can change the domain’s DNS records, which tell browsers where to find an address.
• Record the existing records for the hostname you will change, so you can review the previous configuration.
• List anything else that uses the domain, such as email, and keep unrelated records outside the change.
• Choose one person to make the change and another person, if available, to check the result.

Use a harmless visible detail to identify the intended release, such as an approved heading. Avoid testing solely by recognizing a familiar logo. If two versions look similar, an explicit detail gives you a better check that the address reaches the app you meant to publish.

How do you connect the address without guessing records?

Use the current domain instructions for your app as the source of the record names and values. Do not copy an IP address or verification value from a screenshot of somebody else’s app. If you cannot find an authoritative value for your own setup, pause that change and get the instruction before editing DNS.

1. Confirm the destination app and the complete hostname you want to connect.
2. Read the connection requirements presented for that destination. Note each record’s type, name, and value exactly.
3. Open the DNS service responsible for your domain. Compare its existing entries with the required entries before saving changes.
4. Apply only the records needed for the hostname you chose. Check for an older entry that points that same hostname elsewhere.
5. Return to the app’s connection instructions and complete any requested verification, then test the full address in a browser.

If the domain service asks whether a record name is relative to your domain, check its explanation before entering a full hostname. The useful habit is to compare the final saved name with the intended address. Catching a repeated domain name or a missing subdomain is easier than debugging it later.

How do you check the published app?

Check publication separately from code synchronization. Lovable’s Git sync guide↗ (opens in a new tab) says that pushing code updates the editor preview, while publishing the live site is a separate action. Seeing your change in the editor is therefore not enough evidence that a visitor has it.

1. Open the published app at its existing live address and check the identifying detail you chose.
2. Type the full custom address into a fresh browser tab rather than reusing an editor preview.
3. Confirm the address bar shows the intended hostname and a secure connection without a warning.
4. Open an important inner page directly, then refresh it. Test the path a visitor will actually follow.
5. Complete one harmless core action, such as opening a public page or submitting a test form that you control.

Use a phone as well as your usual computer when the app serves phone users. Record the address and visible outcome of each check. The aim is evidence of a usable app, rather than a screenshot that only proves a homepage loaded once.

What should you check when the address fails?

Start by identifying where the failure appears. Compare the existing live address with the custom address, and compare the bare domain with any subdomain you configured. Change one suspected cause at a time. Several simultaneous edits make it harder to know what fixed the problem.

If the app itself needs investigation, Lovable Plan mode is a separate way to review a proposed code change before implementation. Keep a domain problem distinct from an app change until you have evidence connecting them. For reusable requests, the Lovable prompt library helps make your instructions more specific.

What belongs in your publication checklist?

Keep the main address, the app it should reach, the approved release detail, and the checks that passed. Include the exact path and symptom for anything unresolved. Store a date with the result so an assistant can distinguish a past successful check from evidence about the current release.

Write the next step as something another person can do: “Check the saved hostname against the required record,” rather than “Domain broken.” Do not save passwords or sign-in links. How fenbs works explains how that small work record stays available to connected assistants; the AI at work guides cover similar ways to keep useful session outcomes.

How to keep your publication checks with fenbs

Keep the checks so you can carry on from exactly where you left off, on any device and in any other AI. The useful record says what works, what does not, and which small check comes next.

1. Create a free account.
2. Connect Lovable to fenbs through Integrations. The connection is yours to use and may be restricted by your workspace administrator.
3. Save the address you chose and a short list of the pages and actions that must work.
4. After testing, save what passed, the exact symptom of any failure, and the next step. Keep passwords out.
5. When you return, ask your connected AI to read the saved work before suggesting more changes.

Lovable describes personal connection setup in its custom connector guide↗ (opens in a new tab). fenbs keeps your work record; it does not manage DNS or publish your app. A one-time address change with no handoff may need only a short checklist. If choosing how to continue development is the bigger question, see Lovable versus Claude Code.