<p>An example will be maybe worth a thousand words:</p>

<pre><code>$ sudo apt install git
$ ssh 192.168.0.110
kub@host:~$ git init --bare repo1 
Initialized empty Git repository in /home/kub/repo1/
kub@host:~$ logout
Connection to 192.168.0.110 closed.
</code></pre>

<p>Voila, We already posses a self-hosted version control system. Let's use it as an example client:</p>

<pre><code>$ git clone 192.168.0.110:repo1 /tmp/r
Cloning into '/tmp/r'...
</code></pre>

CC BY-SA 4.0
2019-10-30T19:54:19.140Z
I fail to see how this is 'self' hosted. This or something very similar has to be done on any git server self hosted or otherwise
Bruce Becker
CC BY-SA 4.0
2019-10-31T08:49:51.727Z
This is self hosted in so far, that the code is stored on a different machine in a local network.
Bernhard Döbler
CC BY-SA 4.0
2019-10-31T10:15:58.237Z
Yes, this is an example, but what does it teach the OP and later visitors? Is this how you properly set up a self-hosted Git server? What is the meaning of `192.168.0.110`? What if that machine's hard drive crashes? This may be a little helpful if you know what you're doing, but obviously the OP is not, and this does not help them.
CodeCaster
CC BY-SA 4.0
2019-10-30T18:59:56.233Z
2019-10-30T18:59:56.233Z
kubanczyk
<p>Assume you have your own IT infrastructure, eg a Linux server or a good old mainframe, on which you are running (hosting) your VCS software of choice, e.g GIT or ChangeMan ZMF. In such case you have a self hosted hosted VCS. As compared to GitHub, which is a web-based hosting service for software development projects using Git.</p>

CC BY-SA 4.0
2019-10-30T08:35:32.533Z
Nothing wrong with this answer, but I think a more verbose and explicit one may also have a place here :)
Bruce Becker
CC BY-SA 4.0
2019-10-30T06:29:45.717Z
2019-10-30T06:29:45.717Z
Pierre.Vriens
<blockquote>
  <p>What is self hosted version control system</p>
</blockquote>

<p>A version control system hosted in a location you control and administer yourself.</p>

<p>Git is designed as a "distributed version control system", this means that by default every user has a complete copy of the history. It's not strictly necessary to even have a central server at all, though it is generally very inconvenient not to.</p>

<p>At a minimum a shared git repo can simply be a shared directory that you all have access to on a unix-like system you can all ssh into.</p>

<p>Most people however would like something a bit fancier than that, they may want the ability to let people perform some write actions on the repo without giving them full access to do anything they like to it. They may want a web interface to browse the code. They may want issue-tracking that integrates with the repo, they may want a pull-request system. </p>

<blockquote>
  <p>and how is it different from github?</p>
</blockquote>

<p>Github mostly operates as a cloud-service*, your code is stored on servers owned and controlled by github. They provide hosting for git repos, along with a bunch of related services like issue tracking and pull-requests. Initially their model was that public repos were free and private ones cost money. Since the microsoft takeover they have started offering limited private repos for free, but if you want to do serious private collaboration you are going to have to pay them.</p>

<p>The advantage of cloud-services is that you don't have to expend any effort on maintaining the service. The downside is the operator of the cloud service can screw you over at any time and there is little you can do about it. </p>

<p>With git the risk is somewhat less than with other cloud services because as I mentioned earlier the actual version control history is kept by every client, so you can set up a new git server, switch your clients over and as far as the code itself is concerned things can continue as before. However you still risk losing the other stuff like the issue tracker, pull requests, permission setups etc.</p>

<p>If you want to self-host a git service with integrated web interface, issue-tracking and pull-requests then the main option i'm aware of seems to be gitlab. </p>

<p>* They do offer a self-hosted option for "Github Enterprise", but their website says nothing about how much it costs.....</p>

CC BY-SA 4.0
2019-10-31T18:57:42.053Z
2019-10-31T18:57:42.053Z
Peter Green
<p>Let's take it word by word:</p>

<ul>
<li><strong>Self</strong>: You or your organisation owns this thing. By contrast, a cloud-based offering by GitHub.com, Azure, GitLab.com, etc. (see <a href="https://en.wikipedia.org/wiki/Comparison_of_source-code-hosting_facilities" rel="nofollow noreferrer">this list on Wikipedia</a> for a more comprehensive list) is not owned by you, but rather the service provider in question. Do not confuse ownership of the <em>code</em> (dictated by it's license – typically owned by you), with ownership of the service for performing version control on the code.</li>
<li><strong>Hosted</strong>: You or your organisation are responsible for <em>operating</em> and <em>maintaining</em> this thing. In some cases, this is exactly the same software (e.g. one can self-host GitLab or run GitHub Enterprise “on premise” in your own datacentre). This means keeping it secure, making any changes to it, serving user requests for change, etc. You are also responsible for some part of the infrastructure necessary to provide this service. This may vary, depending on who you have service provision agreements with, from everything down to the power and networking, or only the last layer of the service (here, the version control system itself), or anything in between.</li>
<li><strong>"version control system"</strong> (or VCS): anything (software or otherwise, but most likely software) which provides the functionality necessary to control versions. Note there is a subtle difference between <a href="https://en.wikipedia.org/wiki/Version_control" rel="nofollow noreferrer">Version Control</a> and <a href="https://en.wikipedia.org/wiki/List_of_version-control_software" rel="nofollow noreferrer">Version Control Software</a>, although the meaning is often conflated.</li>
</ul>

<p>The term VCS can refer to any version control system, even when it is not applied to software, however in our context, it can be assumed that you are referring to a version control system <strong>applied to software</strong>.</p>

<p>In other words, a “self-hosted VCS” can be thought of as:</p>

<blockquote>
  <p>A service and all of its components which is under your own ownership and control, acting as a version control system for software.</p>
</blockquote>

<p>Often, this can take the form of:</p>

<ul>
<li>base infrastructure (network/power/server),</li>
<li>operating system,</li>
<li>authentication and authorisation mechanism, and</li>
<li>the VCS server itself (Git, SVN, etc.).</li>
</ul>

<p>The second part of your question is about how it is different from GitHub. The following contrast can be made:</p>

<ol>
<li>Functionally there may be differences between what you can do with GitHub an what you can do with your self-hosted VCS. GitHub, as is the case for almost all VCS hosted by third parties (i.e., <strong>not</strong> hosted by you) goes a few steps further than simply doing version control. There are collaboration tools, identity management, issue tracking, etc. built into their service. While this is strictly speaking not part of VCS, it greatly improves the experience of using one, almost to the point where doing version control without them feels impossible.</li>
<li>GitHub owns and operates the service. You may make suggestions to change their service, API, etc., and perhaps even contributions to their open source products, but you do not own the service. It is provided to you based on the SLA for the offering that you choose. You cannot make your own changes to it. This is overall a very good thing, unless you are in the business of providing the VCS itself – but chances are that you just want to <em>use</em> the service, not compete with it.</li>
</ol>

<p>Update to answer the edited question:</p>

<blockquote>
  <p>does it get uploaded to the server, or it is saved on my local machine? If it is uploaded to the server, then if I reset the computer, will I able to access my code again?</p>
</blockquote>

<p>You are conflating two issues here: self-hosting and <strong>distributed version control</strong>. Of course, if you self-host <em>on your own computer</em>, your run the risk of losing everything if the machine dies. However, of <em>someone else</em> hosts your code in only one place, then you <em>still</em> risk losing everything if <em>their</em> machine goes down.</p>

<p>To address this (and several other issues related to centralisation of source control), <strong>distributed version control</strong> was invented. A good discussion is <a href="https://git-scm.com/book/en/v2/Getting-Started-About-Version-Control" rel="nofollow noreferrer">in the git book</a>.</p>

CC BY-SA 4.0
2019-10-30T09:09:02.613Z
I think this is a great answer, maybe a good addition would be to start from the contrary but well known examples: public services "in the cloud" github.com and gitlab.com are NOT self hosted services.
Ta Mu
CC BY-SA 4.0
2019-10-30T09:10:08.037Z
Thank you for the suggestion I'll update it
Bruce Becker
CC BY-SA 4.0
2019-10-30T14:51:28.003Z
I feel slightly confused by this answer. Does this mean that I cannot self-host GitLab because I don't own it or I am not responsible to mantain it? I know it is possible to self-host GitLab, but this answer could imply it is not.
bracco23
CC BY-SA 4.0
2019-10-30T14:54:08.810Z
Yes, you have a point. The same argument could be made for GitHub Enterprise. I will update the answer to make it explicit that I am referring to GitLab/GitHub.com vs GitLab/GitHub *product*
Bruce Becker
CC BY-SA 4.0
2019-10-31T18:35:42.333Z
You've made the world "self" and "hosted" more complicated than they need to be! Self = Yours; Host = server.
jpaugh
CC BY-SA 4.0
2019-10-30T08:34:55.123Z
2019-11-01T10:02:26.327Z
2019-11-01T10:02:26.327Z
Bruce Becker
<p>A "self hosted version control system" is one that is used for tracking its own source code.</p>

<p>When a new version control system is developed, initially no version control is used for it, or some existing version control.</p>

<p>Eventually, a major milestone is reached when the version control system is good enough for handling its own source code. At that point, the developers are motivated to actually switch to it; and thereby it has become self-hosted.</p>

<p>This is a similar concept to a self-boostrapping compiler: a compiler written in its own language. You need that compiler to compile that compiler, just like you need a running version of a self-hosting version control system in order to check out its own sources.</p>

<p>Every serious version control system is self-hosted, because if it isn't, it shows that the authors don't have confidence in it; would you use Git if the development of Git relied on something else, like Mercurial?</p>

<p><strong>This is not to be confused with a "self-hosted repository" which is just a version control repository that you host yourself on a machine that you control instead of using someone else's hosting service like gitlab.</strong> </p>

CC BY-SA 4.0
2020-08-24T10:36:25.930Z
Sorry, I believe you have the premise entirely wrong. It's not about who "owns" the version control tool. It's about who owns the hosting infrastructure and if that's the same as who owns the IP being placed under version control.you got the first statement correct.
Ian W
CC BY-SA 4.0
2019-10-31T19:23:37.340Z
2019-10-31T19:23:37.340Z
Kaz
<p>What is self hosted version control system and how is it different from github? I mean if I use self-hosted VCS then where does my code go? I mean: does it get uploaded to the server, or it is saved on my local machine? If it is uploaded to the server, then if I reset the computer, will I able to access my code again?</p>

CC BY-SA 4.0
2019-10-31T07:38:24.370Z
Thank you all of you; but 1 thing i didn't understood is that if i use self hosted VCS then where does my code goes, i mean it gets uploaded on the server or it is saved on my local machine. If it uploaded on the server ,then if i reset the computer , will i able to access my code again.
Qasim Arthuna
CC BY-SA 4.0
2019-10-31T18:33:49.910Z
Anything "self hosted' means that you set up your own *host* (i.e. server). So, it would go to *your* server, not some canonical "the" server out there in the cloud. When you download the purchased software, you'll then have to install it somewhere; and  wherever you install it is where your code will live.
jpaugh
CC BY-SA 4.0
2019-11-01T07:31:47.477Z
I self host Subversion on my own laptop. Subversion makes `.svn` subdirectories for everything under version control and that's where each version of your code goes
Mawg
<github><distributed-systems>
What is self hosted version control system?
Qasim Arthuna
# What is self hosted version control system?

(Asked by: username_0 on 2019-10-30)

What is self hosted version control system and how is it different from github? I mean if I use self-hosted VCS then where does my code go? I mean: does it get uploaded to the server, or it is saved on my local machine? If it is uploaded to the server, then if I reset the computer, will I able to access my code again?

**Tags:** github, distributed-systems

> **Comments:**
> **username_0**: Thank you all of you; but 1 thing i didn't understood is that if i use self hosted VCS then where does my code goes, i mean it gets uploaded on the server or it is saved on my local machine. If it uploaded on the server ,then if i reset the computer , will i able to access my code again.  
> **username_1**: Anything "self hosted' means that you set up your own *host* (i.e. server). So, it would go to *your* server, not some canonical "the" server out there in the cloud. When you download the purchased software, you'll then have to install it somewhere; and  wherever you install it is where your code will live.  
> **username_2**: I self host Subversion on my own laptop. Subversion makes `.svn` subdirectories for everything under version control and that's where each version of your code goes  

---

## 5 answers

### Answer by username_4 on 2019-10-30. Score: 23

Let's take it word by word:

* **Self**: You or your organisation owns this thing. By contrast, a cloud-based offering by GitHub.com, Azure, GitLab.com, etc. (see [this list on Wikipedia](https://en.wikipedia.org/wiki/Comparison_of_source-code-hosting_facilities) for a more comprehensive list) is not owned by you, but rather the service provider in question. Do not confuse ownership of the *code* (dictated by it's license – typically owned by you), with ownership of the service for performing version control on the code.
* **Hosted**: You or your organisation are responsible for *operating* and *maintaining* this thing. In some cases, this is exactly the same software (e.g. one can self-host GitLab or run GitHub Enterprise “on premise” in your own datacentre). This means keeping it secure, making any changes to it, serving user requests for change, etc. You are also responsible for some part of the infrastructure necessary to provide this service. This may vary, depending on who you have service provision agreements with, from everything down to the power and networking, or only the last layer of the service (here, the version control system itself), or anything in between.
* **"version control system"** (or VCS): anything (software or otherwise, but most likely software) which provides the functionality necessary to control versions. Note there is a subtle difference between [Version Control](https://en.wikipedia.org/wiki/Version_control) and [Version Control Software](https://en.wikipedia.org/wiki/List_of_version-control_software), although the meaning is often conflated.

The term VCS can refer to any version control system, even when it is not applied to software, however in our context, it can be assumed that you are referring to a version control system **applied to software**.

In other words, a “self-hosted VCS” can be thought of as:

> A service and all of its components which is under your own ownership and control, acting as a version control system for software.

Often, this can take the form of:

* base infrastructure (network/power/server),
* operating system,
* authentication and authorisation mechanism, and
* the VCS server itself (Git, SVN, etc.).

The second part of your question is about how it is different from GitHub. The following contrast can be made:

1. Functionally there may be differences between what you can do with GitHub an what you can do with your self-hosted VCS. GitHub, as is the case for almost all VCS hosted by third parties (i.e., **not** hosted by you) goes a few steps further than simply doing version control. There are collaboration tools, identity management, issue tracking, etc. built into their service. While this is strictly speaking not part of VCS, it greatly improves the experience of using one, almost to the point where doing version control without them feels impossible.
2. GitHub owns and operates the service. You may make suggestions to change their service, API, etc., and perhaps even contributions to their open source products, but you do not own the service. It is provided to you based on the SLA for the offering that you choose. You cannot make your own changes to it. This is overall a very good thing, unless you are in the business of providing the VCS itself – but chances are that you just want to *use* the service, not compete with it.

Update to answer the edited question:

> does it get uploaded to the server, or it is saved on my local machine? If it is uploaded to the server, then if I reset the computer, will I able to access my code again?

You are conflating two issues here: self-hosting and **distributed version control**. Of course, if you self-host *on your own computer*, your run the risk of losing everything if the machine dies. However, of *someone else* hosts your code in only one place, then you *still* risk losing everything if *their* machine goes down.

To address this (and several other issues related to centralisation of source control), **distributed version control** was invented. A good discussion is [in the git book](https://git-scm.com/book/en/v2/Getting-Started-About-Version-Control).

> **Comments:**
> **username_9**: I think this is a great answer, maybe a good addition would be to start from the contrary but well known examples: public services "in the cloud" github.com and gitlab.com are NOT self hosted services.  
> **username_4**: Thank you for the suggestion I'll update it  
> **username_10**: I feel slightly confused by this answer. Does this mean that I cannot self-host GitLab because I don't own it or I am not responsible to mantain it? I know it is possible to self-host GitLab, but this answer could imply it is not.  
> **username_4**: Yes, you have a point. The same argument could be made for GitHub Enterprise. I will update the answer to make it explicit that I am referring to GitLab/GitHub.com vs GitLab/GitHub *product*  
> **username_1**: You've made the world "self" and "hosted" more complicated than they need to be! Self = Yours; Host = server.  

---

### Answer by username_3 on 2019-10-30. Score: 5

An example will be maybe worth a thousand words:
$ sudo apt install git
$ ssh 192.168.0.110
kub@host:~$ git init --bare repo1 
Initialized empty Git repository in /home/kub/repo1/
kub@host:~$ logout
Connection to 192.168.0.110 closed.

Voila, We already posses a self-hosted version control system. Let's use it as an example client:
$ git clone 192.168.0.110:repo1 /tmp/r
Cloning into '/tmp/r'...

> **Comments:**
> **username_4**: I fail to see how this is 'self' hosted. This or something very similar has to be done on any git server self hosted or otherwise  
> **username_5**: This is self hosted in so far, that the code is stored on a different machine in a local network.  
> **username_6**: Yes, this is an example, but what does it teach the OP and later visitors? Is this how you properly set up a self-hosted Git server? What is the meaning of `192.168.0.110`? What if that machine's hard drive crashes? This may be a little helpful if you know what you're doing, but obviously the OP is not, and this does not help them.  

---

### Answer by username_7 on 2019-10-30. Score: 5

Assume you have your own IT infrastructure, eg a Linux server or a good old mainframe, on which you are running (hosting) your VCS software of choice, e.g GIT or ChangeMan ZMF. In such case you have a self hosted hosted VCS. As compared to GitHub, which is a web-based hosting service for software development projects using Git.

> **Comments:**
> **username_4**: Nothing wrong with this answer, but I think a more verbose and explicit one may also have a place here :)  

---

### Answer by username_8 on 2019-10-31. Score: 2

> What is self hosted version control system

A version control system hosted in a location you control and administer yourself.

Git is designed as a "distributed version control system", this means that by default every user has a complete copy of the history. It's not strictly necessary to even have a central server at all, though it is generally very inconvenient not to.

At a minimum a shared git repo can simply be a shared directory that you all have access to on a unix-like system you can all ssh into.

Most people however would like something a bit fancier than that, they may want the ability to let people perform some write actions on the repo without giving them full access to do anything they like to it. They may want a web interface to browse the code. They may want issue-tracking that integrates with the repo, they may want a pull-request system.

> and how is it different from github?

Github mostly operates as a cloud-service\*, your code is stored on servers owned and controlled by github. They provide hosting for git repos, along with a bunch of related services like issue tracking and pull-requests. Initially their model was that public repos were free and private ones cost money. Since the microsoft takeover they have started offering limited private repos for free, but if you want to do serious private collaboration you are going to have to pay them.

The advantage of cloud-services is that you don't have to expend any effort on maintaining the service. The downside is the operator of the cloud service can screw you over at any time and there is little you can do about it.

With git the risk is somewhat less than with other cloud services because as I mentioned earlier the actual version control history is kept by every client, so you can set up a new git server, switch your clients over and as far as the code itself is concerned things can continue as before. However you still risk losing the other stuff like the issue tracker, pull requests, permission setups etc.

If you want to self-host a git service with integrated web interface, issue-tracking and pull-requests then the main option i'm aware of seems to be gitlab.

\* They do offer a self-hosted option for "Github Enterprise", but their website says nothing about how much it costs.....


---

### Answer by username_11 on 2019-10-31. Score: 1

A "self hosted version control system" is one that is used for tracking its own source code.

When a new version control system is developed, initially no version control is used for it, or some existing version control.

Eventually, a major milestone is reached when the version control system is good enough for handling its own source code. At that point, the developers are motivated to actually switch to it; and thereby it has become self-hosted.

This is a similar concept to a self-boostrapping compiler: a compiler written in its own language. You need that compiler to compile that compiler, just like you need a running version of a self-hosting version control system in order to check out its own sources.

Every serious version control system is self-hosted, because if it isn't, it shows that the authors don't have confidence in it; would you use Git if the development of Git relied on something else, like Mercurial?

**This is not to be confused with a "self-hosted repository" which is just a version control repository that you host yourself on a machine that you control instead of using someone else's hosting service like gitlab.**

> **Comments:**
> **username_12**: Sorry, I believe you have the premise entirely wrong. It's not about who "owns" the version control tool. It's about who owns the hosting infrastructure and if that's the same as who owns the IP being placed under version control.you got the first statement correct.  

---

