Lovable GitHub repo is public: make it private and rotate secrets

Open the repository in GitHub, go to Settings, then Danger Zone, then Change visibility, and select Private. Then rotate every secret that the code or the git history ever held. Making the repository private stops new visitors. It does not remove copies that people made while the repository was public.

This guide shows how to make the repository private, how to find who changed it, and how to find and rotate the secrets. It also shows what to do about forks and old commits.

Does Lovable GitHub sync make a repository public?

According to the Lovable GitHub documentation, Lovable creates a new repository when you connect a project. The repository is “private by default, so nobody can see your code unless you change its visibility on GitHub.”

The page does not describe a way to change the visibility inside Lovable. It says that you change visibility in the GitHub settings.

The docs do not describe a case in which Lovable makes a repository public. For this reason, treat a public repository as a change that someone made in GitHub, until you show otherwise. Four causes are common:

1. You or a team member changed the visibility in GitHub, for example to share the code.
2. A different repository is public. Git sync always creates a new repository, and it cannot link to an existing one. You may look at an older repository from an earlier export or test.
3. You disconnected the project and connected it again. The Lovable docs say that reconnecting creates a new repository, and the original stays unchanged and unlinked. The old one keeps its old visibility.
4. An organization setting or an organization owner changed the visibility.

Note: I could not verify any other cause in the vendor docs. If none of the four causes fits, ask the people who have admin access to the repository. Then continue with the steps below. The steps are the same for every cause.

How do I confirm that the repository is public?

Do not use your own browser for this test, because you are signed in. A signed-in owner can see a private repository.

1. Open a private window in your browser. Do not sign in to GitHub.
2. Open the address of your repository, for example https://github.com/your-name/your-repo.
3. If you see the code, the repository is public. If you see a “404” page, it is private.

You can also test from a terminal. This command makes no sign-in:

git ls-remote https://github.com/your-name/your-repo.git

If the command lists branch names and commit hashes, the repository is public. If it asks for a user name or fails, the repository is private. Run this test only on repositories that you own.

Then check the other repositories that Lovable made. Open each project in Lovable and note which repository it uses. Check the visibility of each one in GitHub.

What do I do first? Fix it now, in order of urgency

Do these steps in order. Steps 1 and 2 stop new exposure. Steps 3 to 6 remove the risk from copies.

1. Make the repository private. The GitHub visibility documentation gives these steps. Open the repository. Click Settings. In the “Danger Zone” section, click Change visibility. Select Private. Confirm the effects and click Make this repository private.
2. Tell your team to stop sharing the link. Anyone who has the address can still clone it while it is public. After step 1, they lose access unless they are collaborators.
3. List the secrets. Search the code and the history. See the next section.
4. Rotate every secret that you find. Delete the old key or password at its source. Create a new one. Store the new one as a server-side secret.
5. Check the logs of each service. See the damage section.
6. Deploy with the new secrets. The old secrets must not stay in the live app.

Caution: If you cannot change the visibility, an organization owner may have restricted this ability. The GitHub docs say that an organization owner can limit visibility changes to organization owners. Ask an owner to make the change.

Do not delete the repository as your first action. The Lovable docs say that deleting the repository stops the sync. Deleting also removes your own evidence of what was public.

How do I find the secrets in my repository?

Search the current files and the full history. A secret that you removed in a later commit stays in the old commits.

Start with the files. Look for these items:

• Files named .env, .env.local, or .env.production.
• Keys in the source code, such as sk-, Bearer, or apikey.
• Database URLs that contain a password.
• Supabase keys. The public anon key is meant for the browser. The service_role key is not. Read what to do about a leaked service_role key.
• Webhook secrets and payment keys.
• Service account files, such as JSON files with a private key.

Then search the history. This command prints each commit that touched an environment file:

git log --all --oneline -- '.env*' '*.pem' 'serviceAccount*.json'

This command searches all commits for a text pattern. Replace the pattern with the start of your own key:

git grep -n "sk-" $(git rev-list --all) | head -20

The second command can be slow in a large repository. You can use a dedicated scanner instead. The GitHub guide on removing sensitive data names gitleaks as an example of a pre-commit scanner.

GitHub also scans public repositories. The secret scanning documentation says that it runs automatically for free on public repositories and scans the entire git history on all branches. It creates an alert in the repository when it finds a secret. For some partner providers, GitHub notifies the provider, so the provider can act. Open the Security tab of your repository and read the alerts.

Warning: A scanner finds known formats. It can miss a custom password. Read the code of the configuration files by hand.

Why is a private repository not enough?

Making the repository private changes who can read it from now on. It does not change what people already read or copied.

While the repository was public, anyone could clone it. A clone holds the full history. Automated tools also scan public repositories for secrets. You cannot know who copied the code.

The GitHub docs describe what happens to forks. When you change a repository from public to private, “current forks will remain public and will be detached from this repository.” The fork owner controls each fork. You cannot make those forks private.

For this reason, assume that every secret in the repository was public. The right response is to revoke the secret. The GitHub docs on secret scanning say that you should rotate an affected credential right away. They add that removing it from the history is time-consuming and often unnecessary once the credential is revoked.

How do I rotate the secrets?

Rotate each secret at the service that issued it. Use this order: the secrets with the highest cost or the most data access first.

1. Payment keys and webhook secrets. Create new keys in the payment dashboard. Update the webhook secret in your server settings.
2. Database credentials. Change the database password. For Supabase, rotate the service_role key if it was in the code. Read the Supabase service role key guide for the steps.
3. AI provider keys. Delete the key in the provider dashboard. Create a new key in a separate project, and set a spend limit. If the key was in browser code, read how to fix an exposed OpenAI key.
4. Email and SMS keys. An attacker can send messages from your account. Delete the key and create a new one.
5. Auth secrets. Rotate the JWT secret or the session secret if it was in the code. Rotation signs out your users. This is the correct result.
6. Cloud and storage keys. Delete the key and check the buckets for files that you did not upload.

Put each new secret in the secret store of your host, not in a file in the repository. Read environment variables security for the rules. Add .env* to .gitignore.

Keep a list of what you rotated and when. You need the list if you must report the incident.

How do I check if someone used the secrets?

Read the logs of each service for the whole period in which the repository was public. If you do not know the start, use the date of the first commit that held the secret.

1. Payment provider. Look for refunds, payouts, and new customers that you did not create.
2. Database. Open the logs. Look for large reads, deletes, and sign-ins from unknown sources.
3. AI provider. Open the usage page. Compare the requests with your real traffic.
4. Cloud provider. Look for new servers, new users, and new access keys.
5. Email provider. Look for messages that you did not send.
6. Your own app. Check for user accounts or admin accounts that you did not create.
7. GitHub. Open the Insights page and the Security tab of the repository. Look at the clones, the traffic, and the alerts. Check the list of collaborators and delete people who do not need access.

If you find signs of use, rotate again after you close the access path, and keep the logs. If the repository held personal data of users, ask a lawyer about your duties to tell users or an authority.

Do I need to remove the secrets from the git history?

Maybe. First rotate every secret. After rotation, the old secrets have no value.

Remove them from the history only if the old commits hold content that must stay secret even after rotation. Examples are personal data, private keys that you cannot replace, and customer files.

The GitHub guide on removing sensitive data gives this process:

1. Revoke or rotate the secret first.
2. Rewrite the history on your computer. The guide recommends git-filter-repo, version 2.47 or later, with the --sensitive-data-removal option.
3. Check the result, and count the affected pull requests.
4. Force-push the new history with git push --force --mirror origin.
5. Contact GitHub Support. Support can remove cached views that still show old commits.
6. Tell your collaborators to re-clone or clean their copies. GitHub cannot clean forks or local clones.

Caution: A history rewrite changes every commit hash. It can break the Lovable sync if the sync expects the old history. Make a backup first. Then test the sync on a copy of the project. The Lovable docs do not describe this case, so I could not verify how the sync reacts.

How do I stop it from happening again?

Use these steps to keep secrets out of the repository, whatever its visibility.

1. Treat every repository as public. A private repository can become public in one click. Do not store secrets in it.
2. Keep secrets in the host settings. Use the environment variable store of your host and not a committed file.
3. Use the right prefix. A variable that starts with VITE_ goes into the browser bundle. Do not use it for secrets.
4. Turn on push protection. GitHub offers push protection that blocks a push that holds a known secret format. Check the settings of the repository.
5. Limit who can change visibility. Use an organization and ask the owners to restrict visibility changes. The GitHub docs confirm that an owner can do this.
6. Review the collaborators each quarter. Remove people and apps that do not need access.
7. Check what the deployed app serves. A public repository is one leak path. The live site is another. Source maps and a served .git folder also expose code. Read source maps and exposed git folders.
8. Follow a pre-launch list. The solo founder pre-launch checklist covers these checks in one place.

When should I get help?

Get help in these cases:

• The repository held payment keys, database passwords, or customer data, and you see signs of use.
• You cannot tell which secrets were in the history.
• The repository belongs to a company, and the code is under a contract or a license that limits sharing.
• A rewrite of the history failed, or the Lovable sync stopped after it.
• You see unknown collaborators, deploy keys, or GitHub apps on the repository.

After the fix, repeat the private-window test. Confirm that the address shows a “404” page, that each rotated key fails, and that the live app works with the new secrets.