Should Your Business Website’s GitHub Repository Be Public or Private?

What does repository visibility actually change?

A repository holds your project files and their recorded changes. GitHub’s repository documentation distinguishes public repositories, which are accessible to everyone, from private repositories, whose access is limited to authorized people and applicable administrators.

Public source can make sense for an intentionally open-source project, a demonstration, or code you have permission to share. Private source is often more appropriate for an ordinary business website that contains unpublished copy, implementation details, or assets you are not licensed to redistribute as source.

Neither setting replaces secure handling of passwords, payment information, or customer records. Those do not belong in the website repository in the first place.

Can Cloudflare publish a private repository?

Yes. Cloudflare’s GitHub integration documentation confirms support for public and private repositories. Grant the integration access to the intended repository, select the correct project, and verify the configured production branch.

For a single business website, granting access only to the needed repository is easier to review than granting access to every repository in an account. If an organization requires approval for the integration, work with its owner rather than moving the project into an unrelated personal account to get around the restriction.

After setup, check that a successful deployment corresponds to the expected commit. Making a repository private or public is not the step that determines which version customers see.

What can visitors still see from a private repository?

Assume that anything delivered to the browser can be inspected or saved: HTML, client-side JavaScript, CSS, public images, and data returned by public endpoints. Repository privacy cannot conceal a secret that your build copies into one of those files.

• A public phone number in HTML: visible by design.
• An email-service secret in browser JavaScript: exposed, even if its original source file was private.
• A secret held only by a server-side function: should stay on the server and must not be returned in a response.
• An unpublished preview: may still be public at its preview address unless access protection is configured.

Cloudflare’s secret bindings are designed for server-side credentials. For a concrete example, see how a static website contact form separates the public page from email delivery. Use the preview and production guide before sharing a test site.

Who should control the repository and related accounts?

Choose a repository owner your business can continue to access. Record which person or organization owns GitHub, the Cloudflare project, the domain registration, and the email provider. These can be four different accounts; access to one does not prove control of the others.

Use named collaborator access instead of sharing a login. Match permissions to the job, enable the account’s available security protections, and keep recovery methods current. Agree who can publish production changes and who can approve additional collaborators.

Check platform plan and role limits before choosing an account structure. Write down the ownership arrangement as part of the project agreement; a repository’s visibility label does not establish your intellectual-property rights.

What should you check before changing visibility?

Review current files and their history before making private source public. Old commits may contain information that no longer appears in today’s files. Check licenses, client material, internal notes, source maps, test data, and credentials, and review GitHub’s visibility-change warnings.

Making a public repository private cannot recall copies already downloaded. If a credential was exposed, rotate or revoke it first; deleting a line or changing visibility is not sufficient. Follow GitHub’s sensitive-data removal guidance with the people maintaining the repository.

After any visibility or integration change, recheck collaborator access and the next deployment. Do not make a rushed visibility change as a generic fix for a build failure.

What is a practical ownership checklist?

1. Name the business-controlled repository and its owner.
2. Choose visibility intentionally and review who has access.
3. Confirm which Cloudflare project and branch publish the site.
4. Keep server credentials out of source and browser-delivered files.
5. Record domain, hosting, and email ownership and recovery contacts securely.
6. Test a small update and confirm the business can maintain access after a collaborator leaves.

The BUILD • PUBLISH • OWN IT guide brings repository setup and the publishing workflow together. Compare the responsibilities first in the ChatGPT, GitHub, and Cloudflare overview, or ask Colby about your ownership setup if the accounts are already split across providers.