Making a GitHub repository public exposes all code, commit history, and issues to anyone on the internet. Before changing visibility, check for hardcoded API keys, passwords, and secrets in your code and commit history. Go to Settings, scroll to the Danger Zone, click Change visibility, select Make public, and confirm by typing the repository name.
What Happens When You Make a Repository Public
Making a GitHub repository public means anyone on the internet can see your code, commit history, Issues, Pull Requests, and every file ever committed. This is useful for open-source projects, portfolios, and templates — but it is dangerous if your repository contains API keys, passwords, database URLs, or other secrets. Even if you deleted a secret from the code, it may still be visible in the commit history. Before going public, you need to audit your repository thoroughly. Check every file for hardcoded credentials, review your commit history for accidentally committed secrets, and make sure environment variables are stored in external services (like Supabase Secrets or Vercel Environment Variables) rather than in code. AI tools like Lovable sometimes generate code with placeholder API keys — make sure these are removed or replaced with environment variable references before publishing.
Prerequisites
- A free GitHub account
- A private repository that you own
- A modern web browser
- All API keys and secrets removed from code and stored in environment variables
Step-by-step guide
Audit your code for hardcoded secrets before changing visibility
Audit your code for hardcoded secrets before changing visibility
Before touching any settings, open your repository on github.com. Click the "Code" tab and browse through your files. Look for common secret patterns: lines containing "apiKey", "secret", "password", "token", "sk_", "pk_", "SUPABASE_SERVICE_ROLE_KEY", or any long random strings that look like credentials. Check these files especially: .env files (these should NEVER be in the repository), configuration files, Edge Functions or API routes, and any file with "config" in the name. Use the search bar at the top of the repository and search for terms like "apiKey" or "secret" to find them quickly.
Expected result: You have reviewed all files and confirmed that no hardcoded secrets exist in the current code.
Check your commit history for previously committed secrets
Check your commit history for previously committed secrets
Even if secrets are not in your current code, they might exist in older commits. Click the clock icon or the "commits" link on your repository's Code page to view the commit history. Click on individual commits and look for files that might have contained secrets — especially early commits where AI tools like Lovable or Cursor may have generated configuration files with placeholder keys. If you find secrets in old commits, you will need to rotate those credentials immediately (generate new API keys in Stripe, Supabase, etc.) because making the repo public will expose the entire history.
Expected result: You have reviewed the commit history and identified any commits that may contain sensitive data.
Remove or rotate any exposed secrets
Remove or rotate any exposed secrets
If you found any secrets in your code or commit history, take action before going public. First, rotate the credentials: go to the service (Stripe Dashboard, Supabase Settings, Firebase Console) and generate new API keys. Update your application to use the new keys via environment variables — in Lovable, store them in Cloud tab then Secrets; in Vercel, use the Environment Variables settings. Second, remove any .env files or config files with secrets from the repository by deleting them through the GitHub web interface: navigate to the file, click the trash can icon, commit the deletion.
Expected result: All secrets have been rotated and removed from the current codebase, and new credentials are stored in environment variables.
Navigate to Settings and the Danger Zone
Navigate to Settings and the Danger Zone
Click the "Settings" tab in your repository's top menu bar. Scroll all the way down to the bottom of the General settings page. You will see the "Danger Zone" section outlined in red. Find the row labeled "Change repository visibility" and click the "Change visibility" button. A dialog box appears with the option "Make public."
Expected result: You see the visibility change dialog with a "Make public" option and a list of consequences.
Review the consequences and confirm the change
Review the consequences and confirm the change
GitHub shows a warning listing what will happen: the code, commit history, issues, pull requests, and wiki will become visible to everyone. Anyone can fork the repository, and search engines will index it. Read this carefully. If you are comfortable with the consequences, type the full repository name (in the format "your-username/repository-name") into the confirmation field. The "I understand, make this repository public" button becomes active. Click it. The change takes effect immediately.
Expected result: The repository is now public. The Settings page refreshes and the visibility indicator changes to Public.
Complete working example
1# Pre-Public Repository Checklist23Complete ALL items before making this repository public.45## Secrets Audit6- [ ] No API keys in any source file7- [ ] No .env files committed to the repository8- [ ] No database connection strings in code9- [ ] No OAuth client secrets in configuration10- [ ] No hardcoded passwords or tokens11- [ ] Commit history reviewed for previously deleted secrets12- [ ] All exposed credentials have been rotated1314## Environment Variables15- [ ] VITE_SUPABASE_URL uses environment variable16- [ ] VITE_SUPABASE_PUBLISHABLE_KEY uses environment variable17- [ ] Stripe keys stored in Secrets (not in code)18- [ ] All API keys in deployment platform env vars1920## Content Review21- [ ] README.md is professional and accurate22- [ ] No private business information in Issues23- [ ] No confidential discussions in PR comments24- [ ] License file is present (MIT, Apache, etc.)2526## Final Steps27- [ ] All secrets rotated BEFORE going public28- [ ] Team notified about visibility change29- [ ] AI tool connections verified after changeCommon mistakes when making a GitHub Repository Public Safely
Why it's a problem: Making a repository public without checking the commit history for secrets
How to avoid: Always review old commits, not just current files. Deleted secrets still exist in Git history and become visible when the repo goes public.
Why it's a problem: Assuming that deleting a file with secrets removes it from history
How to avoid: Git preserves every version of every file. If an API key was ever committed, it is in the history forever. Rotate the credential before going public.
Why it's a problem: Forgetting to check AI-generated configuration files
How to avoid: AI tools like Lovable and Cursor sometimes generate config files with placeholder or real API keys. Search for common key patterns before publishing.
Why it's a problem: Not adding a license file before going public
How to avoid: Without a license, your code is technically "all rights reserved." Add a LICENSE file (MIT is most common for open source) by clicking Add file and choosing a license template.
Why it's a problem: Going public without notifying the team
How to avoid: Tell all collaborators before changing visibility. They may have private discussions in Issues or PRs that they do not want to be public.
Best practices
- Complete a full secrets audit before making any repository public
- Rotate all credentials that were ever committed to the repository, even if deleted
- Store all API keys in environment variables, never in source code
- Add a LICENSE file before going public so others know how they can use your code
- Add a professional README.md that explains the project
- Review Issues and Pull Request comments for any confidential business information
- Notify all collaborators before changing visibility
- Use GitHub's secret scanning feature to automatically detect exposed credentials
Still stuck?
Copy one of these prompts to get a personalized, step-by-step explanation.
I'm about to make my GitHub repository public. Give me a comprehensive checklist of security items to verify first, especially for a project built with Lovable that uses Supabase and Stripe.
Frequently asked questions
Is my entire commit history visible when I make a repository public?
Yes. Every commit, every file change, and every deleted file in the history becomes visible to anyone. This is why checking for secrets in old commits is critical before going public.
Can people copy my code if the repository is public?
Yes. Anyone can fork (copy) a public repository. If you add a license like MIT, they must follow its terms. Without a license, your code is technically all rights reserved, but enforcement is difficult.
Can I make the repository private again after going public?
Yes. Go back to Settings, Danger Zone, Change visibility, Make private. However, anyone who forked or cloned the repo while it was public still has their copy.
Will my Lovable or V0 connection break when I change visibility?
Usually not, but it is worth testing. Open your AI tool after the change and verify it can still access the repository. Reconnect the GitHub integration if needed.
Do I need a paid GitHub plan to have a public repository?
No. GitHub's free plan supports unlimited public and private repositories. Public repositories also get free access to GitHub Actions minutes and GitHub Pages hosting.
Can RapidDev help me audit my repository before making it public?
Yes. RapidDev performs security audits on repositories, checks for exposed credentials, helps rotate API keys, and ensures your project is safe to publish publicly.
What is GitHub secret scanning?
GitHub automatically scans public repositories for known secret formats (API keys, tokens, passwords) from partner services like Stripe, AWS, and Supabase. If a secret is detected, GitHub notifies the service provider who may revoke the key.
Should I add a .gitignore file before going public?
Yes. A .gitignore file prevents sensitive files like .env, node_modules, and build artifacts from being committed. Most AI tools create one automatically, but verify it includes .env and any other sensitive files.
Talk to an Expert
Our team has built 600+ apps. Get personalized help with your project.
Book a free consultation