Forem: DanielBetterDevelopers

The Lovable.dev Migration Guide: Moving from personal GitHub to an organization (without breaking sync)

DanielBetterDevelopers — Sun, 07 Dec 2025 18:06:40 +0000

You’ve built a Lovable app. It’s growing. You’re ready to move from your personal GitHub account to a GitHub Organization (maybe for the Pro plan, or just to collaborate with a team).

Naturally, you open your GitHub repository settings, scroll down to the "Danger Zone," and reach for the Transfer Ownership button.

STOP. 🛑

If you transfer that repository while it is connected to Lovable, you will break your sync, likely permanently. Lovable does not support "Bringing Your Own Repository" (BYOR) for existing projects. If you transfer the repo first, Lovable will refuse to reconnect to it and will insist on creating a duplicate.

Here is why the standard migration fails and the correct strategy to move your Lovable project to a GitHub Organization without losing your mind.

The Problem: Lovable is the "Source of Truth"

Most developer tools (like Vercel or Netlify) treat GitHub as the source of truth. You point them to a repo, and they deploy it.

Lovable works the other way around.
Lovable treats its own internal editor as the source of truth. When you "sync" to GitHub, Lovable pushes code out.

Because of this architecture:

You cannot simply link a Lovable project to an existing, transferred repository.
You must let Lovable create the repository itself during the connection process.

If you transfer your repo my-app to my-org/my-app manually, Lovable sees that remote repo as a stranger. When you try to reconnect, Lovable will say, "I need to create a repo," and you'll end up with my-org/my-app-1.

The Strategy: The "Fresh Start" Migration

To migrate successfully, we have to accept a trade-off: We will sacrifice the Git commit history to ensure the sync works perfectly.

We will not move the repo. Instead, we will archive the old one and let Lovable generate a fresh one in the new Organization.

Phase 1: The Safety Net (Backups)

Before touching anything, secure your data.

Code Backup: Run a git pull locally and zip the folder. Keep this safe.
Database Backup: Go to your Supabase Dashboard -> Project Settings -> Database -> Backups. Create a fresh backup.
- Good news: Your Supabase database is loosely coupled. It connects via Project ID, not the GitHub repo. Moving your code will not delete your data.
Rename the Old Repo: Go to your personal GitHub repo and rename it to my-app-legacy. This frees up your preferred name (my-app) for the new organization.

Phase 2: Sever the Connections

You need to disconnect the services to prevent errors during the switch.

Pause Deployments: If you use Coolify, Vercel, or Netlify, pause "Auto Deploy" to stop them from trying to pull from the old URL.
Disconnect Lovable:
- Go to Lovable Project Settings -> Integrations -> GitHub.
- Click Disconnect.
- Note: Your code remains safe inside Lovable.

Phase 3: The "New" Transfer

This is where the magic happens. We don't "transfer" in GitHub. We "reconnect" in Lovable.

In Lovable, go to Settings -> Integrations -> GitHub.
Click Connect Project.
Crucial Step: Select your Organization as the target.
- Tip: If you don't see your Org, you may need to click "Add Organization" to install the Lovable GitHub App on it.
Lovable will ask to create a repository. Name it my-app (since we renamed the old one, this name is available).
Confirm.

Lovable will now push the entire current state of your app to github.com/my-org/my-app as a fresh "Initial Commit". The sync is now live and healthy.

Phase 4: Re-wiring the Infrastructure

Now that the code has a new home, point your other tools to it.

1. Hosting (Coolify/Vercel/Netlify):

Update the Git Source URL to the new organization repo.
Important: Ensure the hosting provider's GitHub App is installed on your new Organization, not just your personal account.
Trigger a manual deployment to verify the pipe is flowing.

2. Supabase (Branching):

Your database connection (URL/Anon Key) stays the same—no changes needed there!
However, if you use Supabase Branching, you must go to Supabase -> Integrations -> GitHub and reinstall the integration on your new Organization repo.

Summary

Migrating a Lovable app isn't just about moving files; it's about respecting the sync engine.

DON'T use the GitHub "Transfer Ownership" button.
DO disconnect and let Lovable create a fresh repo in the Org.
ACCEPT that your Git commit history will reset (but keep the old repo as a read-only archive).

By following this "Lovable-First" approach, you avoid the "Ghost Repository" trap and keep your project shipping smoothly.

Have you migrated a Lovable project recently? Let me know in the comments if you hit any other snags!

Fixing Traefik Misconfiguration When Changing Domains

DanielBetterDevelopers — Thu, 30 Jan 2025 09:17:30 +0000

Deploying a Next.js application on Coolify should be a smooth experience, but we recently ran into an issue when changing the autogenerated domain to a custom one. Despite configuring the correct DNS records, we encountered a No server detected error when trying to access the domain. The root cause? Coolify did not properly update Traefik’s container labels to reflect the new domain.

In this post, I’ll walk through our deployment process, the issue we faced, and the solution we found to fix it.

The Deployment Flow

Set up the project: We deployed our Next.js app on Coolify as usual.
Changed the domain: We updated the automatically generated domain to our desired custom domain.
Successful deployment: The Coolify dashboard showed that the deployment was successful.
Encountered an error: When accessing the custom domain, we got a “No server found” error, despite having the correct DNS records pointing to our server’s IP.

The Issue

Looking at the Traefik configuration, we found that the labels still referenced the autogenerated domain instead of our custom one. Here’s what the incorrect labels looked like:

traefik.enable=true
traefik.http.middlewares.gzip.compress=true
traefik.http.middlewares.redirect-to-https.redirectscheme.scheme=https
traefik.http.routers.http-0-autogenerated.entryPoints=http
traefik.http.routers.http-0-autogenerated.middlewares=gzip
traefik.http.routers.http-0-autogenerated.rule=Host(`autogenerated.example.com`) && PathPrefix(`/`)
traefik.http.routers.http-0-autogenerated.service=http-0-autogenerated
traefik.http.services.http-0-autogenerated.loadbalancer.server.port=3000

Despite the DNS being configured correctly, Traefik was still expecting requests for the old autogenerated domain, leading to a failed resolution for our custom domain.

The Solution

To resolve the issue, we manually updated the Traefik labels to reflect our custom domain. The correct configuration looked like this:

traefik.enable=true
traefik.http.middlewares.gzip.compress=true
traefik.http.middlewares.redirect-to-https.redirectscheme.scheme=https
traefik.http.routers.http-0-custom.entryPoints=http
traefik.http.routers.http-0-custom.middlewares=redirect-to-https
traefik.http.routers.http-0-custom.rule=Host(`customdomain.com`) && PathPrefix(`/`)
traefik.http.routers.http-0-custom.service=http-0-custom
traefik.http.routers.https-0-custom.entryPoints=https
traefik.http.routers.https-0-custom.middlewares=gzip
traefik.http.routers.https-0-custom.rule=Host(`customdomain.com`) && PathPrefix(`/`)
traefik.http.routers.https-0-custom.service=https-0-custom
traefik.http.routers.https-0-custom.tls.certresolver=letsencrypt
traefik.http.routers.https-0-custom.tls=true
traefik.http.services.http-0-custom.loadbalancer.server.port=3000
traefik.http.services.https-0-custom.loadbalancer.server.port=3000

What Changed?

Updated the Host rule: We replaced the old autogenerated domain with our custom domain (customdomain.com).
Added HTTPS routing: The original misconfiguration only handled HTTP, but proper HTTPS routing was necessary.
Ensured TLS settings were applied: We explicitly enabled TLS and Let’s Encrypt for SSL certificates.

Conclusion

Coolify’s automated domain changes didn’t properly propagate to Traefik’s labels, leading to a misconfiguration that prevented our custom domain from resolving correctly. By manually updating the Traefik labels, we were able to restore proper routing.

If you’re running into similar issues, double-check Traefik’s labels and make sure they match your intended domain settings. This can save you a lot of troubleshooting time!

Add new server to Coolify instance

DanielBetterDevelopers — Fri, 11 Oct 2024 14:39:15 +0000

When managing multiple servers and deploying applications, it’s crucial to have a streamlined system that simplifies server management and deployment workflows. Coolify is a powerful, self-hosted platform that allows you to deploy applications with minimal setup. In this guide, we’ll walk through the steps to connect a new server to your Coolify instance and set it up for seamless application deployment. Whether you're using a VPS provider like Hetzner or DigitalOcean, this guide will help you configure secure SSH access, set up key authentication, and validate the server with Coolify for future deployments.

By the end of this tutorial, you’ll have everything in place to deploy your solutions to a newly connected server with ease.

Prerequisites

Server A: Running a Coolify instance for managing deployments.
Server B: A VPS with SSH access via port 22 (e.g., from Hetzner).

Step 1: Purchase and Set Up Server B

Purchase Server B from your preferred VPS provider (e.g., Hetzner, DigitalOcean).
Make sure Server B is up and running. You can access it using SSH:

ssh root@your-server-ip

Note: Ensure port 22 is open to enable SSH access.

[Optional]: Update and secure Server B by running:

sudo apt update && sudo apt upgrade -y

Step 2: Generate RSA SSH Key in Coolify

On Server A, open Coolify and navigate to Keys and Tokens in the side menu.
Click Add to create a new SSH key.
Select Generate new RSA SSH Key. Coolify will create the key for you.
Copy the Public Key that was generated, and then click Continue.

Step 3: Add the Public Key to Server B

On Server B, navigate to the .ssh directory:

cd ~/.ssh/

Open the authorized_keys file with a text editor (e.g., nano):

sudo nano authorized_keys

Paste the Public Key you copied earlier at the bottom of the file.
Save the file with Ctrl + O, press Enter, and exit with Ctrl + X.

Verification: After adding the key, try logging into Server B again using SSH:

ssh root@your-server-ip

If you log in without being prompted for a password, the key was added successfully.

Step 4: Add Server B to Coolify

Return to Coolify on Server A, and navigate to Servers.
Click Add, and provide the following information:

- Name: A descriptive name for Server B.

- IP Address/Domain: The public IP or domain of Server B.

- Private Key: Select the RSA key generated earlier.

- Username: Set to root, unless you’ve changed the default username.

After filling in the details, click Continue.
On the next screen, click Validate Server & Install Docker Engine to complete the setup.

Next Steps

Now that you’ve added Server B to Coolify, you can start deploying applications or Docker containers. Enjoy!