What Files Should I NOT Upload to GitHub?

GitHub repositories are designed for sharing code. Bots scan public repos for API keys within seconds of a push. Private repos reduce casual exposure but do not eliminate risk — collaborators, CI tools, and accidental visibility changes still leak files.

AI coding tools make this worse by generating .env files, embedding keys in source code, and creating config you did not write yourself. You may not even know a secret exists until a scan or a bill alerts you.

The fix is structural: know what never belongs in Git, use .gitignore consistently, and upload a .env.example template so hosts and teammates know which variables to set without seeing real values.

A .env file stores environment variables as key=value pairs: DATABASE_URL, OPENAI_API_KEY, STRIPE_SECRET_KEY, and dozens of others. Your app reads these at startup. Locally, .env is convenient. On GitHub, it is a live broadcast of your secrets.

Never commit .env, .env.local, .env.production, or any variant with real values. Add them all to .gitignore. Create .env.example instead — same variable names, placeholder values like your_key_here or https://example.com.

Some makers think renaming .env to .env.backup or secrets.txt hides it. Bots and scanners look for those patterns too. If the file contains real credentials, it must not be in Git regardless of filename.

• .env → never upload
• .env.local, .env.production → never upload
• .env.example → safe to upload (fake values only)
• Hard-coded keys in .js or .py files → remove and use env vars

Any string that proves identity to a third-party service is a secret: OpenAI keys (sk-...), Stripe secret keys (sk_live_...), AWS access keys, SendGrid tokens, JWT signing secrets, and database passwords.

AI tools sometimes paste these directly into source files — a function with const apiKey = "sk-..." is a ticking time bomb. Search your project for sk_, pk_live, AIza, and password= before your first upload.

If a key was ever committed, assume it is compromised. Deleting the file from GitHub is not enough — history retains it. Rotate the key in the provider’s dashboard and generate a new one.

• OpenAI, Anthropic, Stripe, Twilio, SendGrid keys
• AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY
• Database passwords in connection strings
• OAuth client secrets and JWT signing keys

SQLite files (db.sqlite3, database.db, app.db) often contain real user data from local testing — emails, hashed passwords, session tokens. Uploading them exposes that data and bloats your repo.

Production should use a hosted database (Railway Postgres, Supabase, PlanetScale, etc.) with a DATABASE_URL environment variable. Your local SQLite file stays on your laptop for development only.

Exception: tiny empty SQLite files used only for automated tests sometimes get committed — but for AI-built apps, assume any .db file is unsafe until you verify its contents.

These folders are not secrets, but uploading them causes failed pushes, slow clones, and confused hosts that try to use stale dependencies instead of installing fresh ones.

node_modules/ contains thousands of npm packages — reinstall with npm install. .next/, dist/, and build/ are compiled output — regenerate with npm run build. Python’s __pycache__/ and .venv/ are machine-specific.

Add each to .gitignore. Your host’s build step recreates them. If node_modules was already committed, remove it from Git tracking, add to .gitignore, commit, and push.

• node_modules/ — reinstall from package.json
• .next/, dist/, build/, out/ — rebuild on deploy
• __pycache__/, .venv/, .pytest_cache/ — Python artifacts
• .turbo/, .cache/ — tooling caches

Files ending in .pem, .key, id_rsa, id_ed25519, or .p12 are cryptographic private keys. They prove you are you to servers, SSH hosts, and signing services. Uploading them gives attackers your identity.

SSL/TLS certificates for local HTTPS development sometimes land in project folders. Production certificates usually live on the host or a CDN — not in your repo.

If you find a private key file in your AI-generated project, add the pattern to .gitignore and store the key outside the project directory (e.g. ~/.ssh/ for SSH keys).

• *.pem, *.key — private certificates
• id_rsa, id_ed25519 — SSH private keys
• .p12, .pfx — certificate bundles with private keys
• service-account.json — Google Cloud credentials

A .gitignore file in your project root tells Git which patterns to skip. Create it before your first commit — it is much harder to untrack files already in history.

Start with stack-specific defaults. Node/Next.js projects need .env, node_modules/, and .next/. Django projects need .env, db.sqlite3, __pycache__/, and media/uploads if they contain user files.

Our safe-upload tool generates a starter .gitignore for common AI-built stacks. Review it, commit it, and verify in GitHub Desktop or your editor that sensitive files no longer appear in the staging area.

• One pattern per line in .gitignore
• Lines starting with # are comments
• *.log ignores all .log files in any folder
• Already tracked? Remove from Git, then ignore

Act fast. Assume the secret is public even if the repo is private. Step one: rotate the compromised key in the provider’s dashboard (Stripe, OpenAI, AWS, etc.) — generate a new key and revoke the old one.

Step two: remove the file from your repository. Delete it, commit, and push. Step three: add the filename pattern to .gitignore so it does not return.

Step four: understand that Git history may still contain the secret. For high-risk exposures, GitHub offers secret scanning alerts, and you may need git filter-repo or BFG Repo-Cleaner to purge history — or create a fresh repo if the project is new. When in doubt, rotating keys is the non-negotiable minimum.

Step five: update your local .env and hosting dashboard with the new key values. Redeploy if the app broke when you revoked the old key.

• Rotate key in provider dashboard first
• Delete file from repo and commit
• Add pattern to .gitignore
• Update .env and host env vars with new key
• Consider history purge for severe exposures

Not everything is dangerous. Source code (without embedded secrets), configuration templates, and documentation help you and your host understand the project.

Upload: README.md, package.json, requirements.txt, Dockerfile (without secrets in ENV lines), .env.example, LICENSE, and your application source in src/ or app/ folders.

When unsure about a file, ask: “Would I be okay if a stranger read this?” If no, keep it local or replace with a template.

• README.md — project description and setup steps
• .env.example — variable names with placeholders
• package.json / requirements.txt — dependency lists
• Source code without hard-coded secrets