Why use GitHub for a project nobody else will see? Because “nobody else” includes your future self on a new laptop, the deploy pipeline that needs to run somewhere, the cloud account that needs to know who’s asking, and the AI coding agent that needs to read the rules. GitHub isn’t just where code is stored. On a new project it’s the home address that everything else points at.
This post isn’t a git tutorial. It’s the case for giving every project, including the tiny ones, a private GitHub repository on day one, and what to put in it.
Your laptop is not a backup
A project that exists only on one machine is one spilled coffee away from not existing. Pushing to GitHub turns every commit into an off-site copy with full history.
History is the part people underrate. A backup gives you the latest version. A repository gives you every version, with a message explaining why each change happened. When something breaks on Thursday, you can read what changed on Tuesday. When an AI agent rewrites a file in a way you didn’t want, you can diff it and put it back.
Time Machine, iCloud and Dropbox all back up files. None of them give you git log, git blame or a pull request. For code, those are the features that matter.
Private by default, free forever
The GitHub Free plan is $0 a month and includes unlimited private repositories. There’s no limit on collaborators, no trial period, and nothing that expires. GitHub documents the plan on its pricing page and in the docs on plans.
That changes the default. There’s no reason to keep a project local “until it’s ready to be public,” because private is free. Make the repository private on day one, push every commit, and flip it to public later if you want to. Going the other way (public to private) still leaves forks and clones out in the world, so start closed.
A private repo also solves the quiet problem of secrets in early commits. Everyone has pushed a .env file at least once. In a private repository that’s a mistake you fix. In a public one it’s a mistake somebody else’s scanner finds first.
2,000 free minutes of automated deploys
GitHub Actions is the deploy engine you get for free with the repository. The Free plan includes 2,000 minutes a month for private repositories, documented in GitHub’s Actions billing docs.
What does a small project actually use? A typical build-and-deploy workflow for a static site or a serverless API runs in two to four minutes. Deploy ten times a day, every working day, and you’re at roughly 600 to 900 minutes a month. Most solo projects deploy a lot less than that. The allowance is big enough that you don’t need to think about it until you’re running a test matrix across several operating systems.
The thing Actions gives you isn’t just CI. It’s the habit of deploying from the repository rather than from your machine. git push becomes the deploy command. That has three effects:
- Every deploy is recorded against a commit, so you always know what’s live.
- Nobody (including you) needs production credentials on a laptop.
- Anyone who can open a pull request can ship, which matters the day you add a second person.
This is also what makes speed of iteration possible: if deploying takes a push, you deploy a lot. If it takes a checklist, you batch changes and ship once a week.
GitHub as the identity your cloud account trusts
A GitHub repository can prove who it is to AWS without any stored password or key. That’s what makes keyless deploys possible, and it’s a feature of the repo, not of your laptop.
The mechanism is OpenID Connect. When a workflow runs, GitHub issues it a short-lived signed token that says “this is repository X, on branch Y, running workflow Z.” AWS checks the signature and, if your trust policy allows that exact repository and branch, hands back temporary credentials that expire in about an hour. No access key ever exists to leak. GitHub documents the setup in Configuring OpenID Connect in Amazon Web Services.
The point for this post: the repository becomes the identity. Your AWS account trusts OnSilent-Pty-Ltd/my-project on main, not a person and not a key. That’s a stronger and simpler security model than anything you can build around a laptop. The full walkthrough is in keyless deploys from GitHub Actions to AWS.
The repo is where your AI agent reads the rules
If you build with Claude Code, Codex or Gemini, the repository is also the agent’s workspace, and the files at its root are where the agent learns how to behave.
CLAUDE.md and AGENTS.md sit in the repository and get loaded at the start of every session: which commands run the tests, which directories are off limits, which branch deploys to production. They only work if the agent is working inside a repo that contains them. A loose folder on your desktop has no such file, and the agent starts every session from zero.
There’s a second benefit. Because the agent’s work is committed, you can review it the same way you’d review a colleague’s: as a diff, in a pull request, before it merges. That review step is the cheapest guardrail there is, and it only exists because the code lives in a repository. We go into what belongs in those files in CLAUDE.md and AGENTS.md: the rules file every AI-built project needs.
It’s the first thing anyone asks for
A collaborator, a contractor, a potential acquirer or a new hire will all ask the same question first: “Where’s the repo?” If the answer is “I’ll zip it up,” you’ve already lost a day and some credibility.
The repository is the project’s public record of existence. Issues, pull requests, commit history and a README tell a newcomer what the thing is, how it’s built and how it’s shipped. Those are all free, and they accumulate on their own if the repo exists from the start.
What to put in the first commit
The first commit should contain enough that the repository works as a home, not just a folder. Five files cover it.
| File | Why it’s there |
|---|---|
README.md | What the project is, how to run it locally, how it deploys. Two paragraphs is enough to start. |
.gitignore | Keeps node_modules, build output and .env files out of history. Pick the template for your language. |
CLAUDE.md or AGENTS.md | The rules for AI coding agents: commands, conventions, what not to touch. |
.github/workflows/deploy.yml | The deploy pipeline, even if it only builds for now. Having it exist is what makes git push the deploy command. |
LICENSE (if public) | Skip for private repos. Add before you open it up. |
Notice what isn’t there: no secrets, no credentials, no .env. The deploy workflow authenticates with OIDC, so there’s nothing to store.
A minimal starting .gitignore for a Node project looks like this:
node_modules/
dist/
.env
.env.*
.DS_StoreThen push, confirm the repository is private, and go build. TigerSoup creates this first commit for you, with the README, ignore file, agent rules and workflow already filled in for the project, and connects the repository to its own AWS account in the same step.
Where this fits
A private GitHub repository is item two on our new project setup checklist, right after the cloud account. It’s free, it takes two minutes if you do it by hand, and everything else in a modern setup (deploys, keyless cloud access, agent guardrails) hangs off it.
If you’d rather skip even the two minutes, TigerSoup is a free Mac app that creates the private repository, the first commit and the keyless deploy connection to a fresh AWS account in under a minute. The repository is created in your own GitHub account, so it’s yours from the first push.
