What is Repository Hosting?
Repository hosting is the service of storing a version controlled project on an accessible server so people and tools can share its recorded history. For a Git project, the host provides a remote repository that authorised clients can clone, fetch from and push to. A hosting platform may also provide code review, issue tracking, permissions and automation. The key distinction is that Git records versions; repository hosting makes a shared copy available and governs collaboration around it.
Repository hosting is not automatically website hosting, application deployment or complete backup. Your code can be safely recorded on a host while your application is running somewhere else, your local edits remain unpushed and your project discussions need a separate export. Those boundaries matter when choosing a service, investigating failures or planning recovery.
What exactly is being hosted?
A Git repository contains objects representing file content, directory trees and commits, plus references such as branches and tags. A shared server repository is commonly bare: it holds Git data without a checked out working tree. That is enough to exchange history, but it does not by itself provide a browser dashboard, reviews or an issue tracker.
A software forge is the wider collaboration platform around repositories. It can hold account and project settings, review conversations, access rules and links to automated checks. These records are not all ordinary files inside the Git history. A simple Git server and a full forge can therefore both host repositories while offering very different services.
Service | What it handles | What it does not imply |
|---|---|---|
Git version control | Local commits, branches and comparisons | A publicly accessible shared server |
Repository hosting | Shared history and authorised repository access | Your application is running |
Package or container registry | Built packages, dependencies or container images | The complete source history and review discussions |
Website or application hosting | Files or processes serving users | A version control workflow or full repository backup |
The word repository is also used for package archives. Here the focus is source repository hosting. GitHub Packages, for example, handles packages and container images as a distinct service. GitHub Pages adds static website publication from a repository; that extra capability does not make every hosted project a deployed application.
If you need the underlying working tree, staging and commit model, start with What is Git? This guide concentrates on the server and platform responsibilities that sit around it.
How do clients share a hosted repository?
Each developer normally works in a local clone. The hosting service is a common exchange point, rather than a live shared folder that copies every saved edit between laptops. Saving changes, committing, pushing, fetching and integrating are separate steps.
Clone creates a local repository from the host, usually with an initial branch checked out.
Commit records selected content in the local repository. It does not itself upload that history.
Push sends the necessary objects and requests updates to the specified remote references.
Fetch downloads available history and updates local tracking references without integrating it into the checked out branch.
Merge, rebase or an appropriately configured pull integrates selected history into local work.
Git negotiates which objects need transferring and can send them in a packfile. A later exchange need not resend the entire repository. On a push, the server checks whether the reference update is permitted and returns a result. A transfer can reach the host successfully yet be rejected because of permissions, branch policy or incompatible history.
Modern Git has versioned wire protocols and negotiates capabilities with the server. Protocol v2 separates capability discovery and commands such as reference listing. The actual exchange depends on client and server support, so a conceptual diagram should not be mistaken for a universal packet sequence.
The infographic below shows the shared exchange point and separates the three data layers that need attention in a backup plan.
HTTPS, SSH and the platform login
HTTPS and SSH are common secure transports for remote Git access. HTTPS uses TLS to protect the connection. SSH protects the connection and commonly authenticates the client with a key. The browser session, Git credential and automation identity are different access paths; signing into the website does not guarantee that your terminal has valid credentials.
GitHub's command line authentication guidance documents HTTPS token or credential helper workflows and SSH keys. Its normal account password is not the required HTTPS Git credential. Other hosts have their own supported credential types and policies. Follow the actual host documentation, use appropriately scoped credentials and verify the server identity.
Authentication establishes an identity; authorisation determines what it can do. Being allowed to read or clone a project does not grant permission to push, change settings or merge into a protected branch. An account can pass authentication while a particular repository operation remains forbidden.
Managed hosting versus self hosting
Operating model | Who runs the service? | Main trade off |
|---|---|---|
Managed cloud platform | Provider operates the hosting platform and underlying service | Less platform maintenance, with provider policies and dependencies |
Self hosted forge | Your organisation operates the application and its supporting infrastructure | More configuration control, with patching, monitoring and recovery responsibilities |
Simple bare Git server | You operate Git access and storage without a full forge | Small functional core, with fewer collaboration features unless added |
Managed dedicated instance | Provider runs a dedicated offering under its specific terms | Different isolation and administration boundaries from a shared SaaS service |
Managed hosting does not remove your responsibility for accounts, access rules, safe workflows and recoverable copies. Self hosting does not automatically make a repository private or secure. In both cases, decide who owns the project, who can administer it, what happens when that person leaves and how you would restore service.
Examples of repository hosting platforms
GitHub combines hosted Git repositories with review, project and automation features.
GitLab offers GitLab.com, Self-Managed and Dedicated operating models.
Bitbucket Cloud provides repository collaboration and integrates its Pipelines CI/CD service.
Azure Repos provides Git repositories with pull requests and branch policies within Azure DevOps.
Forgejo is software for operating a self hosted forge, rather than a promise that someone else will manage your instance.
These are examples, not a ranking. Their current primary documentation describes the operating models and features: GitHub, GitLab, Bitbucket Cloud, Azure Repos and Forgejo. Verify the exact offering, plan, integration and export support before choosing. Free repository storage alone says little about review controls, build compute, large file transfer or recovery cost.
Choose according to the work, not the brand
Requirement | Question to ask | Evidence to check |
|---|---|---|
Team collaboration | Can the required reviewers and owners participate? | Roles, review rules and supported integrations |
Private infrastructure code | Who can clone, administer and run automation? | Access scope, credential controls and audit visibility |
Large files or frequent builds | Which separate resources consume allowance? | LFS, artefacts, registry storage, transfer and compute |
Operational control | Who patches, monitors and recovers the platform? | Responsibility boundary and tested restore procedure |
Future migration | Which project data can be exported and restored? | Git refs, large files, metadata and configuration coverage |
Public, private and protected are different
Visibility controls who can discover or read a hosted project under the platform's rules. Branch protection controls which updates can reach particular branches. A private project may have many authorised readers, and a public project can still restrict changes. Visibility and write permission are not the same setting.
Review requirements and automated checks can help protect a main branch. They must actually be configured and tested. Some GitHub branch protection restrictions allow administrator bypass by default, with options to change that behaviour. Feature availability also depends on the plan and repository type. Do not assume a rule exists because a platform advertises it.
Once someone has an authorised clone, removing their server access does not delete that local copy. Changing visibility cannot recall every earlier copy either. GitHub documents that public forks are not made private when the original becomes private. Treat access decisions as decisions about who can retain project history.
Keep tokens, private keys, router passwords and personal data out of tracked content. A deletion in the latest commit does not erase earlier history. If a secret is exposed, revoke or rotate it first and follow a coordinated cleanup process. Automated secret detection is an additional control, not permission to commit secrets.
Repository hosting, CI runners and deployment
A repository event can trigger Continuous Integration when a workflow is configured. A runner executes the build or test job. That runner can be managed by the platform or operated elsewhere; the repository server and build execution machine are separate responsibilities. Deployment then updates a target environment if the configured process allows it.
A green check describes the result of specified checks, not proof that every relevant property was tested. Review what the workflow actually runs, which revision it uses, and whether it can access production credentials or sensitive networks. Code review, automated tests and release approval answer different questions.
Untrusted workflow code can compromise a self hosted runner or obtain resources available to its job. GitHub's security guidance warns about this risk, including for private repositories. Isolate execution, restrict token permissions and control access to secrets. Do not place a general purpose runner on your everyday home lab server simply because it is convenient.
UK broadband and home lab implications
With an external repository host, clone and fetch use your download throughput, while push uses upload throughput. If the host is on your home connection, the direction reverses for visitors: their downloads consume your upstream capacity. The same server can therefore feel fast on the LAN and slow to remote collaborators.
A repository service on a LAN can remain private to that network. Access from elsewhere needs an appropriate reachable path, such as a controlled VPN or carefully secured public service. CGNAT can complicate incoming IPv4 access because forwarding on your own router does not configure the provider's translator. A static IP helps with a stable address but does not increase transfer capacity or configure permissions.
Ordinary access to a hosted service is outbound, so using an external Git host does not normally require opening a port on your router. Before exposing a home server, account for firewall policy, certificates or SSH host keys, access control, patching, power loss and independent backups. The useful first home lab exercise is a private service you can recover.
Techie Broadband calculation: the host's upload bottleneck
These are theoretical payload calculations, not measurements of an ISP or hosting provider. Use decimal MB and sustained payload throughput in Mbps. Ideal seconds = megabytes × 8 ÷ Mbps. Assume a 500 MB initial download and a 50 MB push; actual Git transfer size depends on repository history, compression and objects already available.
Illustrative operation | Payload rate | Ideal transfer time |
|---|---|---|
Download 500 MB from an external host | 100 Mbps downstream | 40 seconds |
Push 50 MB to an external host | 20 Mbps upstream | 20 seconds |
Push the same 50 MB | 100 Mbps upstream | 4 seconds |
Eight remote users each download 500 MB from a home host | 20 Mbps total home upstream | 1,600 seconds aggregate capacity time |
Eight 500 MB downloads total 4,000 MB, or 32,000 megabits. At 20 Mbps aggregate upstream, that represents 1,600 seconds, approximately 26 minutes 40 seconds. If all eight transfers start together and share capacity equally under ideal conditions, each receives 2.5 Mbps and finishes in that same time. This is an illustrative capacity model, not a guarantee about fairness or scheduling.
At the same payload size, increasing throughput from 20 to 100 Mbps makes ideal transfer time one fifth as long, an 80% reduction. Real elapsed time also includes connection setup, authentication, server pack preparation, protocol overhead and local unpacking or checkout. Latency and shared network load can matter even when the package has ample headline bandwidth.
Techie Broadband test: a host is an exchange point
We tested two working clones and one bare shared repository locally with Git 2.51.1 on Linux. The repositories used the local filesystem; this tests Git behaviour, not network speed, cloud availability or a forge's access controls. Developer A pushed an initial router note, and Developer B cloned it.
Action | Shared host | Developer B's working file |
|---|---|---|
A commits a second version without pushing | Still contains the first commit | Still shows the first version |
A pushes the second commit | Now contains both commits | Still shows the first version |
B fetches the host | Both commits available to B's local history | Still shows the first version |
B fast forwards the local branch | No additional host update required | Now shows the second version |
The fetch test left B's HEAD unchanged while origin/main pointed to the newer history. Integrating with git merge --ff-only origin/main updated the working file because B's branch had not diverged. This demonstrates why a successful push does not mean every colleague is already working on the new revision.
We then added a second branch and a tag, made a mirror clone and restored it into a new disposable bare repository. The two branch references and tag matched their source object identifiers, and git fsck --full reported no errors. This checked Git history restoration only. There were no hosting discussions, LFS objects or service settings in the test.
Back up three different data layers
Layer | Examples | Recovery consideration |
|---|---|---|
Git history | Commits, branches, tags and notes | Preserve the required refs and reachable objects |
External contents | LFS files, build artefacts and package images | Fetch or back up their actual contents separately |
Platform data | Reviews, issues, permissions, webhooks and settings | Use supported exports or application backups and recreate exclusions |
A mirror clone is useful for preserving the references the source exposes and their Git history. It is not a full export of every database record on a forge. Hidden server references, unpushed changes, deleted history and data outside Git need separate consideration. A shallow or partial development clone should not be assumed to be a complete archive.
GitHub's backup guide describes mirror cloning and explicitly adds git lfs fetch --all when LFS is used. LFS pointer files live in Git; the large file contents live separately. A backup that contains only those pointers cannot restore the corresponding assets when the external store is unavailable.
For a self managed platform, include its database, necessary configuration and separately stored contents according to the exact installation guide. GitLab documents configuration and secret key files that need additional handling, object storage exclusions and version constraints for restore. A command returning success does not prove that every component you rely on was included.
Replication and a rolling mirror keep another copy current, but can also propagate unwanted deletions or history rewrites. Keep recoverable versions according to your needs, protect backup access separately, and test restoration. Define the tolerable amount of lost work and the tolerable time to recover; a nightly copy alone says nothing about whether either target can be met.
Migration means more than changing a remote URL
Inventory required branches, tags, large files, submodule repositories, review records, issues, packages and service settings.
Identify what the chosen export or importer includes and record exclusions.
Create a controlled destination and arrange a final synchronisation point so new work is not missed.
Transfer Git data and the separately stored contents using supported procedures.
Compare required reference names and object identifiers, then test a fresh clone and any LFS downloads.
Recreate access rules, default branch, webhooks, workflows and credentials, and run a safe test of the integrations.
Update clients to the verified destination URL and retain a recoverable copy of the old state until validation is complete.
git remote set-url origin NEW_URL changes where an existing local remote points; it does not transfer server contents or project metadata. Replace NEW_URL with the verified destination. GitHub's duplication guide also treats LFS transfer separately. Mirror pushing can overwrite or delete destination references, so reserve it for a controlled target under a deliberate migration plan.
Data location and operating cost
For a UK organisation, examine the actual data location and service terms rather than assuming a UK user account means UK storage. Region controls may apply only to a particular offering and particular data classes. GitHub's Enterprise Cloud residency documentation explicitly distinguishes data inside the selected region from certain data stored or transferred outside it.
Compare the whole workload: user access, required controls, Git and large file storage, transfer, build compute, artefact retention, backup and administration. Self hosting adds infrastructure and operating time. Managed hosting can add usage charges or paid feature requirements. No universal monthly price or cheapest platform can be inferred from repository count alone.
Connect and diagnose without guessing
For a first project on a host, choose the intended owner and visibility, create the repository, configure suitable authentication and copy its actual clone URL. Clone it into a new local directory. If importing an existing local project instead, follow the host's specific import workflow rather than accidentally creating conflicting initial histories.
Inspect git remote -v to see the configured fetch and push destinations. Avoid sharing output containing embedded credentials.
Run git ls-remote origin to request the remote's available reference names and identifiers. This read operation tests repository access; it does not prove write permission.
Run git status -sb to inspect the local branch and working state.
Fetch and inspect incoming history before integrating it according to the team's workflow.
Push the intended branch and read the full result. Verify the expected revision on the host rather than assuming silence means the correct project was updated.
These read commands were checked with Git 2.51.1 in the local test environment. git ls-remote lists the remote references it exposes. origin is a conventional remote name, not a particular provider. The host's actual clone URL and branch policy take precedence over a generic example.
Symptom | Likely layer to investigate | Next useful check |
|---|---|---|
Repository not found | URL, repository existence or permissions | Copy the actual clone URL and check account access |
Authentication rejected | Token, key, credential helper or organisation policy | Use the host's authentication procedure |
Read works but push fails | Write permission, branch policy or divergent history | Read the remote rejection and inspect the target branch |
Clone is slow or stalls | Network transfer, server preparation or local checkout | Identify the phase before changing broadband settings |
Code appears but large files are missing | Separate LFS contents or access | Check LFS retrieval and its credentials |
Git restored but reviews are missing | Platform data was not part of the Git export | Restore the supported project metadata backup |
GitHub documents that “repository not found” can indicate either a missing repository or a lack of permission. A host page loading successfully is also not proof that Git access, LFS storage or a runner is healthy. Diagnose the component that failed rather than treating the whole platform as one undifferentiated connection.
Frequently asked questions
Is repository hosting the same as Git?
No. Git is the version control system. Repository hosting provides an accessible shared repository and may add a collaboration platform around it.
Do I need a repository host to use Git?
No. You can use Git locally. A shared host becomes useful when people or automation need an accessible exchange point.
Does pushing code deploy my application?
Only if a configured process performs deployment in response. Storing a revision on a repository host does not itself make an application run.
Is a private repository a complete backup?
No. It holds what you have sent to it and the platform data it maintains. Unpushed work, external files and recovery requirements need separate attention.
Can I host a repository in my home lab?
Yes. You can operate a private Git server or forge. Remote access, upstream capacity, maintenance, security and tested backups then become your responsibilities.
Can I move between Git hosting providers?
Git history is portable, but large files and platform records need separate transfer or export procedures. Verify the destination's data, access rules and integrations.
Key takeaway
Repository hosting gives version controlled work a shared exchange point and, on a forge, a collaboration and control layer. Keep Git history, external assets, platform records and running applications distinct. Choose a host you can operate safely, diagnose by component and test the recovery of everything the project needs.
Sources and verification
Primary documentation checked on 12 October 2026. Sources include the Git project's Pro Git second edition and current Git manuals, GitHub Docs, GitLab Docs, Atlassian Support, Microsoft Learn and Forgejo. Product examples describe documented capabilities rather than guaranteed plan entitlements. The original Git test used version 2.51.1 on Linux; the broadband figures are labelled theoretical calculations.
To explore the related technical concepts used in this Repository Hosting guide, visit our broadband terminology guide.
