I needed to set up a custom domain for a service I built with Lovable.

The service is a tool for comparing car-sharing and rental car costs. I wanted to publish it at car-sharing-vs-rental-car.tool.tielec.blog as a subdomain separate from my main tielec.blog.

I've configured DNS plenty of times before, so I thought, "This should be fine." But since it had been a while, I was honestly a bit anxious. There were several moments where I caught myself thinking, "Wait, which way is it again?" In the end, I realized that what I thought I knew had become surprisingly fuzzy.

Summary: How to Set Up a Custom Domain in Lovable

Here's a step-by-step guide for setting up a custom domain in Lovable. This example uses Onamae.com (a Japanese DNS provider), but the basic flow is the same for other DNS providers.

1. Add a Domain in Lovable's Dashboard

  1. Log in to your Lovable project
  2. Open the project settings
  3. Navigate to the "Domains" section
  4. Click "Add custom domain"
  5. Enter your desired domain (e.g., car-sharing-vs-rental-car.tool.tielec.blog)
  6. Click "Add domain"

You'll see DNS record configuration information like this:

RECORD TYPE HOST NAME VALUE
A car-sharing-vs-rental-car.tool 185.158.xxx.xxx
TXT _lovable_verify.car-sharing-vs-rental-car.tool lovable_verify=xxxxxxxx...

You'll use this information in the next step.

2. DNS Record Configuration

Lovable requires two DNS records: an A record and a TXT record.

A Record

TXT Record

Important Notes:

3. Example Configuration with Onamae.com

Here's how to configure DNS records in Onamae.com's management interface.

Steps

  1. Log in to Onamae.com's management interface
  2. Select "Domain Settings" → "DNS Settings/Forwarding Settings"
  3. Select your target domain and click "Next"
  4. Click "Configure" under "Use DNS Record Settings"

Adding the A Record

Field Value
Host Name car-sharing-vs-rental-car.tool
TYPE A
VALUE 185.158.xxx.xxx (IP shown by Lovable)
TTL 3600 (leave as default)

Adding the TXT Record

Field Value
Host Name _lovable_verify.car-sharing-vs-rental-car.tool
TYPE TXT
VALUE lovable_verify=xxxxxxxx... (string issued by Lovable)
TTL 3600 (leave as default)

After Configuration:

Verifying DNS Propagation

DNS changes can take some time to propagate (usually minutes to hours). Return to Lovable's dashboard, and it will automatically verify the settings. When configured correctly, you'll see "Active" or "Verified" displayed.

What I Learned from Actually Doing It

Here are the points where I realized my "I know this" understanding had become fuzzy.

Subdomain Hierarchy: Which Way Is Correct?

The first thing I struggled with was designing the subdomain structure.

Initially, I was going to use tool.car-sharing-vs-rental-car.tielec.blog. But right before typing it in, my hand stopped. "Wait, is this right?"

I Had the Hierarchy Backwards

When I thought about it carefully, tool.car-sharing-vs-rental-car.tielec.blog would mean:

tielec.blog
└─ car-sharing-vs-rental-car
    └─ tool

"tool exists within car-sharing-vs-rental-car"

But that's backwards. What I actually wanted was: "Individual services exist within the tools category."

That's when it hit me. I had the hierarchy backwards.

The Correct Structure

I ended up using car-sharing-vs-rental-car.tool.tielec.blog.

tielec.blog
└─ tool (role/category)
    └─ car-sharing-vs-rental-car (individual service)

This way, when more tools are added in the future, it can expand like this:

tool.tielec.blog
├─ car-sharing-vs-rental-car
├─ cloud-cost-simulator
└─ pricing-compare

You don't really notice these things until you're about to actually do it.

I almost went ahead with "good enough," but I'm glad I stopped to think.

Expected CNAME, Got A+TXT Instead

With the design decided, I added the domain in Lovable.

Most hosting services show a CNAME record for custom domain setup. So I expected to see a CNAME.

What Actually Appeared

Instead, the screen showed this:

RECORD TYPE HOST NAME VALUE
A car-sharing-vs-rental-car.tool 185.158.xxx.xxx
TXT _lovable_verify.car-sharing-vs-rental-car.tool lovable_verify=xxxxxxxx...

Wait, no CNAME?

For a moment, I thought maybe my understanding was wrong. But since I understood how to configure it either way, I thought, "Well, I'll just set it up as instructed."

Still, I was curious, so I looked into it.

A Record = One IP Per Service... Right?

This raised a question.

"If I add an A record every time I create a service in Lovable, does that mean each service gets its own IP address?"

But that can't be right. IPv4 addresses have been exhausted for years—assigning one IP per service would be impossible.

How It Actually Works

After some research, I found that multiple services share the same IP address.

car-sharing-vs-rental-car.tool.tielec.blog
            ↓
      185.158.xxx.xxx   ← Lovable's edge (entry point)
            ↓
   Routing based on HTTP Host header
            ↓
     The corresponding project

In other words, DNS only determines the "entry point." The actual routing to specific projects happens via HTTP Host headers or TLS SNI.

Oh, that makes sense.

Cloudflare, Vercel, and Netlify work the same way. It's obvious when you think about it, but it had been so long that I thought, "Wait, how does that work again?"

TXT Records Prevent Spoofing

So what's the TXT record for?

It's to prove that this domain is linked to this Lovable project.

By requiring a unique string issued by Lovable to be set in DNS, they prevent "spoofing." Without this, anyone could configure someone else's domain on their project.

"I Know This" Had Become Fuzzy

Going through this DNS setup after a long time, I realized that what I thought I knew had become surprisingly vague.

I should know this stuff, yet when I actually tried to do it, I thought, "Wait, how does this work again?"

I think this is a common experience for engineers. Knowledge about tasks you don't do regularly becomes fuzzy.

But working through it hands-on helps deepen understanding again. This time, investigating the difference between "CNAME vs A+TXT" helped me reorganize my understanding of DNS.

There's Nothing Wrong with "Checking as You Go"

Feeling "anxious because it's been a while" or thinking "wait, how does this work?" isn't something to be embarrassed about.

If anything, moving forward while thinking "I know this" is more dangerous.

This time, I caught my backwards subdomain hierarchy right before entering it. If I had just gone with "good enough," I would have had to fix it later.

Stopping to ask, "Wait, is this right?"

I think that's surprisingly important as an engineer.

[📦 商品リンク: moshimo-book-dns-textbook]