Publishing a Lovable Project on Your Own Domain

Lovable can publish a project to a permanent lovable.app URL and connect a custom domain on paid plans. It also provides GitHub synchronization when you want your own copy of the code or a separate development workflow.

For many projects, the correct answer is simply to use Lovable's native Publish and Domain settings.

A separate workflow becomes relevant when the result is a static client or campaign site and you want to operate it independently through an AI assistant, maintain release snapshots, collect enquiries, or manage several sites in one place.

This guide covers all three paths.

Path 1: Publish directly from Lovable

Lovable's current publication flow is:

1. Open the project.
2. Click the Publish icon.
3. Choose the public URL.
4. Configure website access.
5. Review the favicon, title, description, and social image.
6. Run the available security check.
7. Click Publish.
8. Use Publish → Update when later changes are ready.

Lovable publishes a snapshot. Changes made in the editor do not automatically replace the live version.

That is a useful production property: visitors continue to see the last published snapshot while you work on the next one.

Connecting a custom domain in Lovable

Lovable supports custom domains on paid plans.

The native path is:

1. Publish the project.
2. Open Project Settings → Domains, or open the custom-domain option from the Publish dialog.
3. Buy a domain through Lovable or connect an existing domain.
4. Follow the DNS verification instructions.
5. Set the preferred domain as primary.
6. Republish or verify the live site as instructed.

Use this route when:

• you want to keep the project inside Lovable;
• Lovable's publication controls match the requirement;
• the project uses Lovable services or integrations;
• the team is comfortable maintaining the live site there.

Path 2: Connect Lovable to GitHub

Lovable's GitHub integration provides a separate copy of the code and bidirectional synchronization.

It is useful for:

• backup;
• collaboration with developers;
• branches and code review;
• local editing;
• deployment through another system;
• moving the project outside Lovable.

Lovable's documentation notes that the connected repository becomes the source of truth and that renaming, moving, or deleting it can break synchronization.

Use GitHub deliberately. It introduces a real software workflow, which is valuable for application development but may be unnecessary for a small landing page.

Path 3: Move a static landing page to Deplion

Deplion is relevant when the Lovable project can operate as static HTML, CSS, browser JavaScript, and public assets.

The target operating model is:

• Lovable creates the page;
• an AI assistant prepares the static output;
• Deplion publishes it;
• the same assistant can later update files through MCP;
• Deplion keeps project versions, domain settings, forms, and rollback.

This route is not suitable for a Lovable application that depends on server-side logic, private environment variables, authentication, database operations, or platform-specific runtime services.

First decide what you are moving

A visual landing page and a full web application can look similar in the editor.

Inspect the project for:

• database integrations;
• authentication;
• server functions;
• private environment variables;
• API routes;
• payment logic;
• file uploads;
• user accounts;
• administrative dashboards.

If any of these are essential, treat the project as an application.

If the page only presents content, runs browser interactions, and sends a contact form, it may be a good static candidate.

Preparing the project

Step 1: Connect GitHub for code access

Use Lovable's GitHub connector to create and synchronize the repository.

After synchronization:

git clone <repository-url>
cd <project-folder>
npm install

Use the scripts defined in package.json to run and build the project.

Do not rely on a generic command without checking the actual project configuration.

Step 2: Ask Lovable to prepare a static version

Example instruction:

Prepare this project as a static marketing website.

Keep the visual design, responsive layout, content, and browser interactions.
Remove authentication, database operations, server functions, and private runtime dependencies.
Do not expose secrets.
Keep the contact form interface and document its expected fields.

Review the code diff before accepting the change.

Step 3: Verify the built output

Check:

• every route;
• images and font files;
• absolute and relative URLs;
• mobile layout;
• page metadata;
• social preview data;
• third-party scripts;
• form behavior;
• console errors.

If the project contains several routes, test direct navigation to each route—not only navigation from the home page.

Step 4: Connect Deplion through MCP

In a compatible AI client, add:

https://deplion.cc/mcp/deplion

Complete authorization and enable the connector.

Then ask the assistant:

Create a Deplion project from this reviewed static build.
Preserve the file structure.
Configure the contact form for lead collection.
Publish a review version and return the URL.

Step 5: Run acceptance checks

Before attaching the domain:

• submit the form;
• test navigation;
• check the page on a phone;
• inspect the browser console;
• verify the title and description;
• check social sharing;
• confirm that no private configuration is visible;
• make one small test edit;
• confirm that the previous release can be restored.

Step 6: Move the domain

A low-risk domain move follows this sequence:

1. Keep the current Lovable site available.
2. Publish and approve the Deplion version.
3. Reduce DNS TTL in advance when appropriate.
4. Change the required DNS records.
5. Verify the domain in Deplion.
6. Test HTTPS, the www variant, redirects, and forms.
7. Keep the previous project available until the new path is stable.

Do not delete the source project immediately after a domain change.

Native Lovable versus Deplion

The right choice depends on where you want the ongoing work to happen.

Common migration mistakes

Moving an application as though it were a static page

A visual preview does not reveal every runtime dependency.

Breaking the form

The form markup may survive the move while the original processing function does not.

Exposing credentials

Client-side code is public. Private keys must never be included.

Changing the domain before acceptance

Approve the new publication first. DNS should be one of the last steps.

Asking the AI to recreate the previous version

Restore the known-good release. Do not use conversational memory as the recovery mechanism.

A practical decision rule

Stay with Lovable when you want Lovable to remain both the creation and publication environment.

Use GitHub when a developer workflow or independent source copy is the priority.

Use Deplion when the deliverable is a static landing page and the ongoing job is to manage publication, domains, enquiries, versions, rollback, and AI-assisted maintenance.

The main idea

Lovable already provides a complete native route to a public URL and custom domain. That should be the default for projects that belong in Lovable.

A separate Deplion workflow is useful when the page is becoming an independently operated static asset—especially for freelancers and small agencies managing multiple client landing pages.