Tools: Setting Up Custom Domains in Lovable: Subdomain Design & A+TXT Records

The Setup ## Subdomain Design: Getting the Hierarchy Right ## What the Hierarchy Actually Means ## Why It Matters ## Wait, A+TXT Records? Not CNAME? ## How DNS Routing Works in Lovable ## Does Each Service Get Its Own IP? ## Why A+TXT Instead of CNAME? ## The Actual Setup Process ## Step 1: Add Domain in Lovable ## Step 2: Configure DNS Records ## A Record ## TXT Record ## Step 3: Wait for DNS Propagation ## Step 4: Verify in Lovable ## On Looking Things Up ## Why It's Okay to Look Things Up ## Looking Things Up Is a Healthy Practice ## Takeaways When setting up a custom domain in Lovable, you'll encounter A + TXT records instead of the usual CNAME. This post covers: I recently configured a custom domain for a service I built with Lovable: https://car-sharing-vs-rental-car.tool.tielec.blog/ I already had tielec.blog running, so I wanted to set up a subdomain for this new tool. DNS setup isn't something I do every day, so I figured I'd double-check things as I went. Turns out, that was a good call. First decision: subdomain structure. At first, I was leaning toward the first option. But then I paused and thought about what it actually represents: Pattern 1: tool.car-sharing-vs-rental-car.tielec.blog This means "tool inside car-sharing-vs-rental-car" — which is backwards. Pattern 2: car-sharing-vs-rental-car.tool.tielec.blog This means "car-sharing-vs-rental-car inside the tool category" — which is what I actually wanted. The second structure makes it easier to scale: It's a small detail, but getting the hierarchy right from the start saves you from awkward migrations later. Once I had the subdomain design figured out, I added the domain in Lovable. I expected to see a CNAME record (like most hosting services), but instead, Lovable showed this: Wait, A record instead of CNAME? I know how to set it up, but I was curious: why not CNAME? Here's what I learned. At first, I wondered: does Lovable assign a unique IP address to each service? Multiple services share the same IP address (the Lovable edge/CDN). DNS just points to the entry point. The actual routing to the correct project happens via: This is the same approach used by Cloudflare, Vercel, and Netlify. If every service needed its own IP, we'd run out of IPv4 addresses pretty quickly. Root domain support CNAME doesn't work on root domains (example.com). A records do. Flexibility A records don't conflict with certain DNS setups (like CNAME flattening). Domain ownership verification The TXT record proves you own the domain, preventing someone else from hijacking it. Here's how I configured it (using Onamae.com, but the process is similar for other DNS providers). In your Lovable project settings, add the custom domain. You'll see the A and TXT record values. Important: The TXT value must match exactly. Copy-paste carefully. DNS changes can take anywhere from a few minutes to a few hours (sometimes up to 48 hours). You can check propagation with: Once DNS has propagated, click "Verify" in Lovable. If everything's correct, HTTPS will be enabled automatically. Here's something I've been thinking about. I've been an engineer for over 10 years (testing → infrastructure → SRE lead → HR → startup founder). But I still look things up when doing tasks like this. For a moment, I wondered: Am I lacking skills? But then I realized: No, this is completely normal. Technology keeps changing DNS setup 10 years ago isn't quite the same as DNS setup today. Every hosting service has its own quirks. You forget things you don't use often I do DNS configuration maybe a few times a year. Of course I don't remember every detail. "Knowing but not checking" is riskier Having experience can trick you into thinking "I know this already." Taking a moment to double-check is actually the safer approach. "Looking things up while working" isn't a sign of skill gaps — it's a sign of good engineering habits. Taking the time to verify assumptions helps you: I almost went with tool.car-sharing-vs-rental-car instead of car-sharing-vs-rental-car.tool. If I hadn't paused to double-check, I would've had to redo the setup later. Pausing to ask "Wait, is this right?" is valuable. Here's what I learned from this experience: If you're working with Lovable (or any hosting service), take a moment to understand the design decisions behind your subdomain structure. It'll save you headaches down the road. I write more about engineering decisions and reflection processes at: https://tielec.blog/ Templates let you quickly answer FAQs or store snippets for re-use. Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse CODE_BLOCK: tielec.blog └─ car-sharing-vs-rental-car └─ tool Enter fullscreen mode Exit fullscreen mode CODE_BLOCK: tielec.blog └─ car-sharing-vs-rental-car └─ tool CODE_BLOCK: tielec.blog └─ car-sharing-vs-rental-car └─ tool CODE_BLOCK: tielec.blog └─ tool (category) └─ car-sharing-vs-rental-car (individual service) Enter fullscreen mode Exit fullscreen mode CODE_BLOCK: tielec.blog └─ tool (category) └─ car-sharing-vs-rental-car (individual service) CODE_BLOCK: tielec.blog └─ tool (category) └─ car-sharing-vs-rental-car (individual service) CODE_BLOCK: tool.tielec.blog ├─ car-sharing-vs-rental-car ├─ cloud-cost-simulator └─ pricing-compare Enter fullscreen mode Exit fullscreen mode CODE_BLOCK: tool.tielec.blog ├─ car-sharing-vs-rental-car ├─ cloud-cost-simulator └─ pricing-compare CODE_BLOCK: tool.tielec.blog ├─ car-sharing-vs-rental-car ├─ cloud-cost-simulator └─ pricing-compare CODE_BLOCK: car-sharing-vs-rental-car.tool.tielec.blog ↓ 185.158.xxx.xxx ← Lovable's edge (shared) ↓ Routing via HTTP Host header / TLS SNI ↓ Your specific project Enter fullscreen mode Exit fullscreen mode CODE_BLOCK: car-sharing-vs-rental-car.tool.tielec.blog ↓ 185.158.xxx.xxx ← Lovable's edge (shared) ↓ Routing via HTTP Host header / TLS SNI ↓ Your specific project CODE_BLOCK: car-sharing-vs-rental-car.tool.tielec.blog ↓ 185.158.xxx.xxx ← Lovable's edge (shared) ↓ Routing via HTTP Host header / TLS SNI ↓ Your specific project COMMAND_BLOCK: # Check A record dig car-sharing-vs-rental-car.tool.tielec.blog # Check TXT record dig TXT _lovable_verify.car-sharing-vs-rental-car.tool.tielec.blog Enter fullscreen mode Exit fullscreen mode COMMAND_BLOCK: # Check A record dig car-sharing-vs-rental-car.tool.tielec.blog # Check TXT record dig TXT _lovable_verify.car-sharing-vs-rental-car.tool.tielec.blog COMMAND_BLOCK: # Check A record dig car-sharing-vs-rental-car.tool.tielec.blog # Check TXT record dig TXT _lovable_verify.car-sharing-vs-rental-car.tool.tielec.blog - Subdomain design: tool.service vs service.tool - Why Lovable uses A+TXT records (not CNAME) - How DNS routing actually works behind the scenes - Why "looking things up" is a healthy engineering practice - tool.car-sharing-vs-rental-car.tielec.blog - car-sharing-vs-rental-car.tool.tielec.blog - HTTP Host header - TLS SNI (Server Name Indication) - Root domain support CNAME doesn't work on root domains (example.com). A records do. - Flexibility A records don't conflict with certain DNS setups (like CNAME flattening). - Domain ownership verification The TXT record proves you own the domain, preventing someone else from hijacking it. - Host: car-sharing-vs-rental-car.tool (don't include .tielec.blog) - Value: The IP address Lovable provides (e.g., 185.158.xxx.xxx) - Host: _lovable_verify.car-sharing-vs-rental-car.tool - Value: The verification string (e.g., lovable_verify=xxxxxxxx...) - Technology keeps changing DNS setup 10 years ago isn't quite the same as DNS setup today. Every hosting service has its own quirks. - You forget things you don't use often I do DNS configuration maybe a few times a year. Of course I don't remember every detail. - "Knowing but not checking" is riskier Having experience can trick you into thinking "I know this already." Taking a moment to double-check is actually the safer approach. - Catch mistakes before they happen - Deepen your understanding - Stay current with how things actually work today - Subdomain design matters: Think about hierarchy (role → individual service) - DNS is just the entry point: Routing happens via Host header / SNI - TXT records prevent hijacking: They verify domain ownership - Looking things up is healthy: Don't let experience trick you into skipping verification