A self-hosted private Git server gives you direct responsibility for where repositories live and who can reach them. That can suit an internal development team, an agency separating client projects, or a small organization with infrastructure it already operates. The useful starting point is a service plan: who administers the host, how access is granted, what is backed up, and how work continues when the machine is unavailable.

Start with one noncritical repository and a recovery exercise. A successful first push proves connectivity; a successful restore proves much more. This guide connects the server decisions to the wider Git hosting and deployment workflow, including the boundary between storing source code and publishing a running website.

Choose the service you can maintain

A bare Git repository reached over SSH is a compact option when your team needs clone, fetch, and push operations. A repository platform adds a browser interface and collaboration features, but also introduces application configuration and additional state to protect. Decide whether reviews, issue tracking, fine-grained permissions, and automated builds are requirements before selecting the system.

Write down the operating commitment, not just the installation steps. Name a primary administrator and a substitute, an update window, an access review interval, and a place for recovery instructions. Include responsibility for DNS, storage, network access, and credentials. If every emergency requires one unavailable person, the service already has a reliability problem regardless of its hardware.

Define the repository and runtime boundary

Git hosting stores version history and exchanges changes. It does not automatically run the application inside a repository. A static website still needs a publication step; a Django or WordPress application also needs its appropriate runtime and persistent data. Keep source repositories outside every public website document root, and give deployment its own identity and destination.

Inventory the data around each project. Repository objects, large-file objects, platform databases, uploaded attachments, access settings, and automation configuration may live in separate locations. A developer clone generally does not contain all of this service state. Record the boundaries before promising that a backup or migration covers the whole system.

Establish SSH access without creating a shared identity

Give each person a distinct SSH key and a recorded owner. The server receives public keys; private keys stay with their owners. Verify the server host key through an established administrative channel before trusting a first connection. Investigate unexpected host-key changes instead of bypassing the warning to make an automation job pass.

For a dedicated Git account, a restricted Git shell can limit the commands available through SSH. OpenSSH key restrictions can also disable forwarding and terminal allocation. These controls address different capabilities, so consider both. Test a legitimate clone and push after changing them. Keep a separate administrative session available while validating SSH configuration, so a mistake does not immediately remove your recovery route.

Do not share one private key among a whole team. Individual keys make it possible to withdraw one person's access without redistributing credentials to everyone. Document the same lifecycle for service keys: purpose, owner, allowed repository, renewal method, and removal procedure.

Create a bare repository in a controlled location

A bare repository holds Git data without the checked-out working directory used for editing. The official Git server setup guide explains this basic SSH pattern. Adapt account names, paths, and permissions to your operating system and service design rather than copying a production configuration blindly.

For a local experiment, the following command creates a new bare repository named website.git in your current directory. Run it only in a disposable workspace where that path does not already contain project data. It is a learning example, not a complete server installation:

git init --bare --initial-branch=main ./website.git

On the actual server, have the administrator create the repository under the chosen service account and verify ownership. Grant only the access that role needs. Record its expected default branch and clone address so onboarding does not depend on remembered paths.

Make authorization explicit

Authentication answers which credential connected. Authorization answers which repository and operation it may use. A restricted shell alone is not a repository permission system. If several people share a server account, their keys may inherit that account's filesystem access unless an additional authorization layer restricts them. Choose a platform or maintained access-control mechanism when projects require different readers and writers.

Test permissions with separate representative identities: a reader, a contributor, and an administrator. Confirm that a reader cannot push and that a contributor cannot reach another client's repository. Decide who can alter protected branches or repository settings. A permission model should be understandable enough that a second administrator can review it.

Keep build automation separate

Repository content can include executable build scripts. Treat a build as code execution under the build identity, with whatever files, network routes, and credentials that identity can reach. Give routine builds read access to source and reserve publication credentials for the deployment stage. Review changes to workflow files with the same care as application changes.

Avoid turning a convenient server hook into an unrestricted production shell. A safer design sends an approved revision to a controlled worker, produces an artifact, checks it, and then deploys it through a narrow interface. Our static website deployment guide develops that sequence for generated HTML and assets.

Design recovery around complete project state

Keep independent backups with retention that survives accidental deletion or an unwanted change. A constantly synchronized copy can repeat the original mistake. Protect backup access separately where practical, record the last successful run, and alert when backups become stale. Include recovery keys and service configuration in your plan without storing plaintext secrets in a public repository.

For a repository platform, coordinate backups using its supported method so repository storage and application databases form a consistent recovery point. Include large-file storage when projects use it. Define an acceptable amount of lost work and an acceptable restoration time, then test whether the process meets those targets.

Restore into an isolated destination. Check expected branches and tags, clone the restored project, inspect representative history, and build a known revision. An integrity command such as git fsck can help identify object problems, but a clean result does not establish that every expected branch, attachment, or credential was backed up. The backup and security hub covers these related responsibilities.

Build a small operating routine

Monitor available storage, backup freshness, authentication failures, and service availability. Investigate unusual growth before the disk fills. Schedule operating system, Git, and platform updates, and keep a record of changes that might affect access. Check that an absent administrator's substitute can locate the instructions and perform a restore without borrowing undocumented credentials.

Periodically remove obsolete keys and abandoned automation accounts. When someone leaves, revoke their access promptly, while recognizing that existing local clones cannot be recalled remotely. Handle sensitive material through appropriate access and retention decisions from the beginning.

Use onboarding to test the service

Ask a teammate who did not install the server to follow the written instructions. Have them clone the pilot project, create a harmless change on a new branch, push it, and retrieve it from another checkout. Let them report unclear steps without silently fixing the instructions for them. This exercise reveals assumptions about VPN access, hostnames, permissions, and default branches.

Check capacity against your actual projects as well. Track repository growth, concurrent build demands, and expected large-file storage. Keep build scratch space from exhausting the volume that holds repositories. Establish a response for low storage before relying on an emergency cleanup.

Common mistakes to avoid

  • Publishing a working checkout that includes repository metadata or configuration secrets.
  • Giving every contributor the same broad server account permissions.
  • Treating a mirror as the only retained backup.
  • Running unreviewed project scripts on the repository host with administrative privileges.
  • Testing installation once and leaving restoration undocumented.

Frequently asked questions

Do I need a web interface?

Only if it supports your collaboration needs. SSH Git can cover basic repository exchange. A web platform becomes useful when reviews, discoverability, permission administration, and associated project records justify its maintenance.

Can the server also host my website?

It can share infrastructure, but separate service identities, directories, and permissions. A website compromise should not provide direct write access to private repositories or backups. Separate hosts can make that boundary easier to manage.

Does private hosting replace secret management?

No. Keep production secrets out of committed files, use controlled delivery to the runtime, and rotate exposed credentials. Repository privacy reduces exposure; it does not make every stored value safe.

Make the first rollout reversible

Move a pilot project, verify normal work, and perform the restore drill before migrating critical repositories. Keep the previous source available during validation and communicate which location accepts new changes. Expand only after access, operating ownership, and recovery are clear enough to repeat for the next project.