Skip to content
P.E.A.C.E.Small Business Center

Free, practical business education for our community.

Search
Home

ChatGPT & AI · Lovable

Domains, Publishing, Authentication & Privacy

Separate a public website address from permissions and private information.

Preview is not the same as publishing

Preview is where you inspect work before sharing it as the public site. Publishing puts an approved version at a visitor-facing address. Project visibility, who can open the published site, and permissions inside the app are different controls; check each separately. Do not assume a draft or preview is suitable for secrets. This course gives instructions, but nothing here publishes your project automatically.

Hosting and a domain

Hosting is the service that makes the site available on the internet. A domain is a readable address you register, such as a business name followed by .com; buying it does not build the site or set up email. Lovable provides a publishing path, and a custom domain depends on the current plan and setup. You can start with the platform-provided address where available rather than buying a domain immediately. Compare renewals and ongoing costs, not only an introductory offer.

Connect an address carefully

DNS is the set of directions that tells internet services where your domain should go. Follow the values shown in your project's domain controls and the registrar's instructions. Do not copy guessed values from a general lesson. Save the existing settings before changing them, especially business-email records. Domain verification and secure-connection setup can take time. HTTPS encrypts information in transit; it does not make badly configured access rules safe.

Authentication is checking who signed in

Authentication means confirming a person's identity for sign-in. Authorization means deciding what that person may do. A public service website usually does not need visitor accounts. If a future owner area needs sign-in, use a supported authentication service and enforce owner permissions behind the scenes. Hiding an Admin button is not protection. Never create shared default passwords or grant owner access to everyone who signs up.

Privacy applies to the whole journey

Write down information collected by forms, accounts, uploads, and connected tools. Check the tools' current privacy and data-use terms. Give visitors a clear notice about real practices, not a copied promise you cannot fulfill. Limit access, keep only what you need, and plan deletion and recovery. Cookie and consent requirements vary with location and tools used. Do not add analytics — visitor tracking — just because a builder suggests it. Ask a qualified adviser about requirements for your particular business.

Approve a launch deliberately

Before publishing, confirm content permission, working links, privacy notices, access rules, costs, and your domain settings. Keep sample records and fake business details out of the public version. After publishing an approved real site, open its actual visitor address on a phone and repeat the main task. Later edits may require a publishing update; follow the current controls and verify the public version. A backend or service change can affect live behavior separately from page publishing, so treat it carefully.

Example prompts to copy and adapt

Replace [BRACKETS] with approved details. Use pretend information for practice, never passwords or customer records.

  • Pre-publish privacy review

    Review this project before any publishing. List public pages, collected information, connected services, visitor/owner permissions, sample content, and unresolved security issues. Explain what needs manual verification. Do not invent a privacy guarantee, create default credentials, change domain/email settings, or publish.

A real-world example

A cleaning website can stay public with no visitor login. An owner-only request list, if added later, must require sign-in AND behind-the-scenes owner permission. A yellow 'Private' label on a page does not protect the customer records.

Steps to take

  1. Explain domain versus hosting in your own words.
  2. List which parts of your proposed site should be public and which need restricted access.
  3. Locate the current publishing and domain settings without publishing the practice project.
  4. Exercise: name why HTTPS and a hidden menu cannot replace proper permissions.

Public and private check

This checklist is optional and not saved. Copy it to keep a personal note. Do not enter sensitive information.

Go deeper in related modules

Not sure what a word means? Check Business Words Made Simple.

Official provider guides

Independent resources, not P.E.A.C.E. partners or recommendations. Check current terms before buying.