5 ms·

selfhost something like gitea with drone And then set up the users Then set up the permissions And the hooks And move repos to it Then set up deployments,

selfhost something like gitea with drone And then set up the users Then set up the permissions And the hooks And move repos to it Then set up deployments, figuring out how to replace any missing Gitlab features Then update the docs that describe how the repo structure works for onboarding Etc etc Moving infrastructure is a couple of days work at least for a small team. If you factor than cost into it then it's rarely worthwhile. And that's before any time lost to investigating and fixing outages, updating the software, and so on.

fendy3002 4y ago
People are severely underestimating how complicated it is to host a private server, even if they go to self hosted gitlab which essentially the same. The amount of downtime, sudden server crash, problem with SSL with NAT, setting up gitlab runner, upgrading, etc. You'll need someone experienced enough and maybe even a dedicated infra role to handle those things
- Aeolun 4y ago
  > You'll need someone experienced enough and maybe even a dedicated infra role to handle those things Depends on where you are are doing it. AWS makes it ridiculously easy to hand off basically all aspects of hosting. Set up once, use forever.
  - nicce 4y ago
    AWS does not go to this category. You are literally paying for them to handle these matters.
- simfree 4y ago
  We've been running Gitlab for over half a decade with over 100 repos, runners on Windows, Linux and Mac with minimal need for maintenance. Same story for the primary free software project we rely on (who we have a support contract with). Neither us nor them spend anywhere close to 10 hours a year on maintaining selfhosted Gitlab related infrastructure.
- linspace 4y ago
  > People are severely underestimating how complicated it is to host a private server People underestimate consistently how complicated is to build reliable things, hardware or software. There is a world between "it works for me" and "it works for all"
  - pooper 4y ago
    And dysfunctional organizations. I worked as a contractor at one place where we simply used the shared file server as a git remote. Reasoning was if the file server was down, it would come back up quickly because it affects everyone. I didn't understand this reasoning until I got emails from the database team saying the database servers stopped working and every development team now needs to change their connection string from machinename-abc.corp to machinename-bcd.corp How in the world someone could write an email like that is beyond me. Ok machines crash all the time but why can't they reuse the same name for the new machine?
    - dizhn 4y ago
      Full DNS propagation used to easily take up to two days back in the day. It might be that.
- L6489afSMNLNFDa 4y ago
  Outside the ~4 hours I spent setting up GitLab (for the first time) 3+ years ago, I've spent an average of perhaps 10 minutes per month maintaining it (and the runner on a separate server). (And that's literally only because I choose to update it manually since it's usually offline for about 15-30 minutes during updates...)
azinman2 4y ago
Don’t forget backups, testing to make sure they work, etc
KronisLV 4y ago
> Selfhost something like gitea with drone I actually recently did just that, moving over everything from my self-hosted GitLab instance into Gitea, Drone CI and Nexus: https://blog.kronis.dev/articles/goodbye-gitlab-hello-gitea-nexus-and-drone https://blog.kronis.dev/articles/goodbye-gitlab-hello-gitea-... (the same would apply when moving from a cloud GitLab instance to the other self-hosted solutions) Edit: fixed the link now. Honestly, it wasn't so bad, given that I didn't couple what I had too tightly to the functionality of GitLab in particular - having an external issue tracker, though moving CI and build artifact storage systems can indeed necessitate porting them over (which was easy, given that I mostly use Dockerfiles and shell scripts for builds anyways) and cause additional work. > And then set up the users; Then set up the permissions; And move repos to it Thankfully, nowadays neither is too hard to do, given that there are pretty good migration scripts which will work, unless you're doing something very non-standard and peculiar. I migrated close to a 100 repositories with not a single failure, though perhaps that's also because I don't mess around with Git LFS after being burnt whilst trying to sync GitLab and GitHub repos with LFS data going into a black hole. > And the hooks; Then set up deployments, figuring out how to replace any missing Gitlab features The good thing here in particular was the fact that I use Docker for builds as mentioned before, so getting "docker build -t ... -f ... ." working across different build systems is generally pretty easy (except for Jenkins which is needlessly hard sometimes), especially when the software for the CI runner nodes themselves runs in Docker containers (with trusted code you can also just share the Docker socket, otherwise you probably want a DinD setup). Deployments are also just telling another system (Portainer/Docker Swarm in my case; sometimes Helm for Kubernetes) that it should retrieve the latest build artifacts from some OCI compatible repo and run the new version of the application with any given configuration. > Then update the docs that describe how the repo structure works for onboarding I don't think that I've ever actually needed to change this, since while the UI itself does change (e.g. organizations vs groups), the actual contents of a particular repository itself remain the same. Might need to update an URL or two, but for the most part I saw no blockers here. > Moving infrastructure is a couple of days work at least for a small team. If you factor than cost into it then it's rarely worthwhile. It took me less than a day, total. But maybe that's because I've built a bit of a pipeline around running containers in my infrastructure and have the ingress/reverse proxy setup around them all established. Not to sound cocky, there are also caveats and things that I do agree with you in regards to pain points (below). > And that's before any time lost to investigating and fixing outages, updating the software, and so on. This is probably the bigger issue here, though. All of the sudden, the stability of it all is your responsibility. Now, in my case that wasn't such a change in circumstances because I started out with GitLab and with my limited hardware setup moving over to Gitea and friends was actually a win from a resiliency standpoint vs an integrated GitLab Omnibus install (that loves to eat RAM). For for anyone moving from the cloud to an on-prem infrastructure, this is definitely one of the main concerns. That said, for many out there storing their code and other stuff in the cloud is a non-starter (e.g. certain government orgs or enterprises), which is where self-hosting can indeed be very helpful, though in most cases I've seen GitLab instances be used instead of Gitea. That said, Gitea is also an excellent option for anyone who just wants to embrace self-hosting out of principle or other reasons. Being in control of your data is pretty cool (at least until you misconfigure something and everyone is in control of your data). That said, if you don't buy into the balkanization of software platforms nowadays too much and focus on the common standards of the systems instead, overall it's not as painful as one might think. Of course, you can also pick a platform that's too hard to actually use and administer (which is why I switched away from GitLab) by yourself, but then the question becomes of why you're even using it in the first place. Honestly, GitLab is an excellent platform with amazing features, but handling updates and its hardware requirements wasn't fun: https://blog.kronis.dev/everything%20is%20broken/gitlab-updates-are-broken https://blog.kronis.dev/everything%20is%20broken/gitlab-upda... Oh, also sometimes migrating data can be downright hellish, like when I tried migrating SVN to Git, with migration scripts not working due to non-standard repo layouts, which meant that I had to rewrite the layouts and history on the SVN end so things would actually work properly and those scripts wouldn't hang. Though it was ages ago and I haven't used SVN that much recently, Tortoise SVN was a nice piece of software though, RIP.

fendy3002 4y ago

People are severely underestimating how complicated it is to host a private server, even if they go to self hosted gitlab which essentially the same. The amount of downtime, sudden server crash, problem with SSL with NAT, setting up gitlab runner, upgrading, etc. You'll need someone experienced enough and maybe even a dedicated infra role to handle those things

Aeolun 4y ago
> You'll need someone experienced enough and maybe even a dedicated infra role to handle those things Depends on where you are are doing it. AWS makes it ridiculously easy to hand off basically all aspects of hosting. Set up once, use forever.
- nicce 4y ago
  AWS does not go to this category. You are literally paying for them to handle these matters.
simfree 4y ago
We've been running Gitlab for over half a decade with over 100 repos, runners on Windows, Linux and Mac with minimal need for maintenance. Same story for the primary free software project we rely on (who we have a support contract with). Neither us nor them spend anywhere close to 10 hours a year on maintaining selfhosted Gitlab related infrastructure.
linspace 4y ago
> People are severely underestimating how complicated it is to host a private server People underestimate consistently how complicated is to build reliable things, hardware or software. There is a world between "it works for me" and "it works for all"
- pooper 4y ago
  And dysfunctional organizations. I worked as a contractor at one place where we simply used the shared file server as a git remote. Reasoning was if the file server was down, it would come back up quickly because it affects everyone. I didn't understand this reasoning until I got emails from the database team saying the database servers stopped working and every development team now needs to change their connection string from machinename-abc.corp to machinename-bcd.corp How in the world someone could write an email like that is beyond me. Ok machines crash all the time but why can't they reuse the same name for the new machine?
  - dizhn 4y ago
    Full DNS propagation used to easily take up to two days back in the day. It might be that.
L6489afSMNLNFDa 4y ago
Outside the ~4 hours I spent setting up GitLab (for the first time) 3+ years ago, I've spent an average of perhaps 10 minutes per month maintaining it (and the runner on a separate server). (And that's literally only because I choose to update it manually since it's usually offline for about 15-30 minutes during updates...)

azinman2 4y ago

Don’t forget backups, testing to make sure they work, etc

KronisLV 4y ago

> Selfhost something like gitea with drone I actually recently did just that, moving over everything from my self-hosted GitLab instance into Gitea, Drone CI and Nexus: https://blog.kronis.dev/articles/goodbye-gitlab-hello-gitea-nexus-and-drone https://blog.kronis.dev/articles/goodbye-gitlab-hello-gitea-... (the same would apply when moving from a cloud GitLab instance to the other self-hosted solutions) Edit: fixed the link now. Honestly, it wasn't so bad, given that I didn't couple what I had too tightly to the functionality of GitLab in particular - having an external issue tracker, though moving CI and build artifact storage systems can indeed necessitate porting them over (which was easy, given that I mostly use Dockerfiles and shell scripts for builds anyways) and cause additional work. > And then set up the users; Then set up the permissions; And move repos to it Thankfully, nowadays neither is too hard to do, given that there are pretty good migration scripts which will work, unless you're doing something very non-standard and peculiar. I migrated close to a 100 repositories with not a single failure, though perhaps that's also because I don't mess around with Git LFS after being burnt whilst trying to sync GitLab and GitHub repos with LFS data going into a black hole. > And the hooks; Then set up deployments, figuring out how to replace any missing Gitlab features The good thing here in particular was the fact that I use Docker for builds as mentioned before, so getting "docker build -t ... -f ... ." working across different build systems is generally pretty easy (except for Jenkins which is needlessly hard sometimes), especially when the software for the CI runner nodes themselves runs in Docker containers (with trusted code you can also just share the Docker socket, otherwise you probably want a DinD setup). Deployments are also just telling another system (Portainer/Docker Swarm in my case; sometimes Helm for Kubernetes) that it should retrieve the latest build artifacts from some OCI compatible repo and run the new version of the application with any given configuration. > Then update the docs that describe how the repo structure works for onboarding I don't think that I've ever actually needed to change this, since while the UI itself does change (e.g. organizations vs groups), the actual contents of a particular repository itself remain the same. Might need to update an URL or two, but for the most part I saw no blockers here. > Moving infrastructure is a couple of days work at least for a small team. If you factor than cost into it then it's rarely worthwhile. It took me less than a day, total. But maybe that's because I've built a bit of a pipeline around running containers in my infrastructure and have the ingress/reverse proxy setup around them all established. Not to sound cocky, there are also caveats and things that I do agree with you in regards to pain points (below). > And that's before any time lost to investigating and fixing outages, updating the software, and so on. This is probably the bigger issue here, though. All of the sudden, the stability of it all is your responsibility. Now, in my case that wasn't such a change in circumstances because I started out with GitLab and with my limited hardware setup moving over to Gitea and friends was actually a win from a resiliency standpoint vs an integrated GitLab Omnibus install (that loves to eat RAM). For for anyone moving from the cloud to an on-prem infrastructure, this is definitely one of the main concerns. That said, for many out there storing their code and other stuff in the cloud is a non-starter (e.g. certain government orgs or enterprises), which is where self-hosting can indeed be very helpful, though in most cases I've seen GitLab instances be used instead of Gitea. That said, Gitea is also an excellent option for anyone who just wants to embrace self-hosting out of principle or other reasons. Being in control of your data is pretty cool (at least until you misconfigure something and everyone is in control of your data). That said, if you don't buy into the balkanization of software platforms nowadays too much and focus on the common standards of the systems instead, overall it's not as painful as one might think. Of course, you can also pick a platform that's too hard to actually use and administer (which is why I switched away from GitLab) by yourself, but then the question becomes of why you're even using it in the first place. Honestly, GitLab is an excellent platform with amazing features, but handling updates and its hardware requirements wasn't fun: https://blog.kronis.dev/everything%20is%20broken/gitlab-updates-are-broken https://blog.kronis.dev/everything%20is%20broken/gitlab-upda... Oh, also sometimes migrating data can be downright hellish, like when I tried migrating SVN to Git, with migration scripts not working due to non-standard repo layouts, which meant that I had to rewrite the layouts and history on the SVN end so things would actually work properly and those scripts wouldn't hang. Though it was ages ago and I haven't used SVN that much recently, Tortoise SVN was a nice piece of software though, RIP.