# GitLab availability and preservation of VTK’s community history
**URL:** https://discourse.vtk.org/t/gitlab-availability-and-preservation-of-vtk-s-community-history/16533
**Category:** Support
**Tags:** proposal, community, infrastructure
**Created:** [September 15, 2026, 5:05pm UTC](https://discourse.vtk.org/t/gitlab-availability-and-preservation-of-vtk-s-community-history/16533 "2026-09-15T17:05:11Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@banesullivan](https://discourse.vtk.org/u/banesullivan)
#### Post date: [September 15, 2026, 5:05pm UTC](https://discourse.vtk.org/t/gitlab-availability-and-preservation-of-vtk-s-community-history/16533/1 "2026-09-15T17:05:11Z")
The current reliability of[gitlab.kitware.com](http://gitlab.kitware.com/) has me concerned for the project’s rich ~30 year history with countless community discussions and contributions.
VTK has become so foundational and impactful that its availability is now critical infrastructure for a broad ecosystem, which is precisely why the current reliability and accessibility of its primary project platform are so concerning.
Yesterday I tried to open a normal issue from an email notification. After more than 30 minutes, the page still would not load. Instead, I was repeatedly presented with the Anubis proof-of-work challenge shown in the attached screenshots. If this were a one-off occurrence, I’d think nothing of it, but this has happened to me what feels like every time I’ve tried to access the GitLab for the last 6 months.
The[GitHub repository mirror](https://github.com/kitware/vtk) is useful, but it is not a substitute for the GitLab project. The issues, merge requests, design discussions, reviews, and other project history are essential parts of the open-source ecosystem. The discussions, code reviews, explanation of decisions, etc form a just as vital part to the value of open source projects as the code itself. When the primary service is inaccessible, that entire body of knowledge is effectively unavailable.
This also raises broader concerns about resilience and continuity. What is the disaster-recovery plan for the GitLab instance and its associated metadata? Is Kitware planning to provide an independently accessible mirror or archival export of the issues, merge requests, and discussions? Not just the Git repository?
The VTK community should not have to treat basic access to a ~30 year project history as uncertain. There are well established solutions and cloud providers that make this a solved infrastructure problem (and I’m willing to bet far more cost effective than what I imagine your current resources are allocated to maintaining this).
The current situation gives users and downstream projects a very poor impression of the project’s openness and reliability.
Speaking from the PyVista community, our users require a dependable foundation for the ecosystem deeply embedded in their 3D workflows. If contributors cannot reliably access the upstream project then that puts everyone at risk.
_Would Kitware please clarify:_
1. What is causing the recurring availability and verification problems?
2. Does Kitware have a rationale for not going with GitLab’s cloud hosting?
3. **What reliability and disaster-recovery guarantees exist for Kitware’s GitLab instance?**
4. Is there a plan to mirror or archive the **full issue, merge request, and discussion history** (along with this discourse) somewhere broadly and reliably accessible?
**This situation is not sustainable, and it needs to be treated as a serious community-infrastructure issue.**
* * *
---
### Author:  [@banesullivan](https://discourse.vtk.org/u/banesullivan)
#### Post date: [September 15, 2026, 5:11pm UTC](https://discourse.vtk.org/t/gitlab-availability-and-preservation-of-vtk-s-community-history/16533/2 "2026-09-15T17:11:31Z")
I also want to note and emphasize that this line on the loading screen has me deeply concerned for the openness of the project.
> Specifically, many endpoints now require a valid login.
I’m not sure what endpoints these are and I’m assuming they are things that put real strain on your infrastructure but gating access behind a login to privately hosted platform is not a good precedent to set for a project with such a rich open source history.
---
### Author:  [@jaswantp](https://discourse.vtk.org/u/jaswantp)
#### Post date: [September 15, 2026, 5:16pm UTC](https://discourse.vtk.org/t/gitlab-availability-and-preservation-of-vtk-s-community-history/16533/3 "2026-09-15T17:16:26Z")
It would be sad to see all the discussions in issues/merge requests be lost should any disaster of such magnitude occur. I hope someone with more knowledge than me can respond to your questions.
---
### Author:  [@Matthew\_Woehlke](https://discourse.vtk.org/u/Matthew_Woehlke)
#### Post date: [September 15, 2026, 5:30pm UTC](https://discourse.vtk.org/t/gitlab-availability-and-preservation-of-vtk-s-community-history/16533/4 "2026-09-15T17:30:45Z")
With the disclaimer that I am not speaking on Kitware’s behalf… I have to say that I find some of the questions raised here a little… odd. Do you ask the same questions about any project hosted on [gitlab.com](http://gitlab.com) or [github.com](http://github.com)? If not, why not? Why would you expect those entities, which have limited commercial interest in many of the projects they host, to be “more sustainable” and less likely to suddenly decide it is no longer worthwhile for them to provide those services, as compared to an entity who has a significant business interest in supporting VTK?
Related, the answer to your second question is self-evident. Critical infrastructure you control is superior to critical infrastructure you don’t. Ironically, the gist of your complaint is that you (understandably) don’t like feeling that VTK’s infrastructure relies on a “third party”. If you feel that way, is it so strange that Kitware does too?
---
### Author:  [@ben.boeckel](https://discourse.vtk.org/u/ben.boeckel)
#### Post date: [September 15, 2026, 5:32pm UTC](https://discourse.vtk.org/t/gitlab-availability-and-preservation-of-vtk-s-community-history/16533/5 "2026-09-15T17:32:29Z")
Speaking for myself based on information I have and feel comfortable providing (e.g., explaining too much about mitigations can make them useless).
> [@banesullivan](#):
>
> I’m not sure what endpoints these are and I’m assuming they are things that put real strain on your infrastructure but gating access behind a login to privately hosted platform is not a good precedent to set for a project with such a rich open source history.
They are those that are HTML renderings of expensive `git` operations. All of these are readily obtainable with a local clone of the repository instead of the world asking us to do uncacheable computation on things oodles of times.
> [@jaswantp](#):
>
> It would be sad to see all the discussions in issues/merge requests be lost should any disaster of such magnitude occur. I hope someone with more knowledge than me can respond to your questions.
The robot has a record of things that are important here.
> [@banesullivan](#):
>
> 1. What is causing the recurring availability and verification problems?
Largely, AI training scraping. Oodles of requests from single IPs for “unimportant” things.
> [@banesullivan](#):
>
> 1. Does Kitware have a rationale for not going with GitLab’s cloud hosting?
We need internal hosting anyways for other reasons, but the features we needed when we migrated from Gitosis (`gitolite`’s predecessor) and Gerrit required functionality not available from `gitlab.com` hosting (e.g., custom instance-wide CI runners). AFAIK, those are still not possible. AFAIK, custom runners require Developer+ access to the target repo for CI to work for MRs from forks (or manual pipeline creation by a Developer+).
> [@banesullivan](#):
>
> 1. Is there a plan to mirror or archive the **full issue, merge request, and discussion history** (along with this discourse) somewhere broadly and reliably accessible?
No plans at the moment; we have the event history for the main repositories going back years. This does miss comment _edits_ because GitLab doesn’t send events for those.
---
### Author:  [@berk.geveci](https://discourse.vtk.org/u/berk.geveci)
#### Post date: [September 15, 2026, 5:40pm UTC](https://discourse.vtk.org/t/gitlab-availability-and-preservation-of-vtk-s-community-history/16533/6 "2026-09-15T17:40:45Z")
Howdy,
I will answer these questions piecemeal because some require detailed information from our sysadmin team and I didn’t want to wait that long before I responded first.
Summary:
- We have backup solutions that are aimed at preserving Gitlab history. Details to follow.
- Due to the overwhelming demand arising from the use of AI, all open git sites are groaning under the pressure. gitlab.kitware is no exception. We have all experienced issues with Github also. Personally, I have had many CI and UI response issues with my native Github repos.
- gitlab.kitware interacts with a very extensive test infrastructure. In fact, this is the main reason why we started hosting VTK on gitlab.kitware. The github infrastructure did not support such an infrastructure at the time. This testing infrastructure is also groaning under the weight of the enormous amount of testing we perform with each MR and leads to performance issues with gitlab itself.
- Our sysadmin team, to which we should all express gratitude, are working hard to keep things functioning well. There is active work happening now to improve the hardware infrastructure.
- We are actively considering moving some of the hosting functionality to Github. Such decisions naturally take longer for a project with a 30 year history so please be patient with us.
---
### Author:  [@banesullivan](https://discourse.vtk.org/u/banesullivan)
#### Post date: [September 15, 2026, 6:18pm UTC](https://discourse.vtk.org/t/gitlab-availability-and-preservation-of-vtk-s-community-history/16533/7 "2026-09-15T18:18:18Z")
> [@Matthew\_Woehlke](#):
>
> Do you ask the same questions about any project hosted on [gitlab.com](http://gitlab.com) or [github.com](http://github.com)? If not, why not? Why would you expect those entities, which have limited commercial interest in many of the projects they host, to be “more sustainable” and less likely to suddenly decide it is no longer worthwhile for them to provide those services, as compared to an entity who has a significant business interest in supporting VTK?
@Matthew_Woehlke, I think this conflates separate issues. Of course [github.com](http://github.com) and [gitlab.com](http://gitlab.com) can have outages. The point is not that large cloud hosted services are infallible… my point is that reliability, operational transparency, and independent preservation are ~solved engineering problems there (and they allocating immense resources to these challenges)
GitHub and GitLab publish public status histories, incident reports, and availability commitments. GitLab documents 24/7 infrastructure monitoring and a 99.9% availability commitment for covered SaaS services, including issues, merge requests, and Git operations ([status](https://status.gitlab.com/), [availability policy](https://handbook.gitlab.com/handbook/engineering/infrastructure-platforms/service-level-agreement/)). GitHub likewise publishes incident histories and detailed availability reports ([status](https://www.githubstatus.com/), [availability report](https://github.blog/news-insights/company-news/github-availability-report-june-2026/)).
> [@Matthew\_Woehlke](#):
>
> Related, the answer to your second question is self-evident. Critical infrastructure you control is superior to critical infrastructure you don’t. Ironically, the gist of your complaint is that you (understandably) don’t like feeling that VTK’s infrastructure relies on a “third party”. If you feel that way, is it so strange that Kitware does too?
No? The gist of my complaint is not that its a third party but that third party (Kitware today) has limited transparency or public commitments to ensuring the posterity of the project and is unintenionally making it more difficult for efforts to try to access and preserve the project by gating access.
GitHub and GitLab exist within a much larger preservation ecosystem:
- [Software Heritage](https://docs.softwareheritage.org/) crawls GitHub and GitLab repositories and preserves source code and development history
- [The Internet Archive](https://archive.org/) provides independent web-page preservation (Wayback Machine))
- [GH Archive](https://www.gharchive.org/) records public GitHub activity, including issues and comments.
As I understand it, Kitware has made any external effort to archive the project very difficult… though I am able to find some issues on the WayBack Machine.
None of this makes those cloud platforms perfect. But it does mean that failure is observable, incidents are communicated, and there are established paths for **independent replication**. That is materially different from relying on a single organization’s private GitLab instance while offering only a code mirror elsewhere.
What happens if something unthinkable happens like Kitware going out of business? Can the community be confident that the ledger and records are independently accessible? It’s hard to go on faith alone for something like that as there would be zero-to-limited business interest in ensuring the posterity of the project in such a case (though I believe wholeheartedly there would be a ragtag team of Kitware engineers who would stage a heist in the name of open source to ensure everything is preserved).
> [@ben.boeckel](#):
>
> The robot has a record of things that are important here.
> [@ben.boeckel](#):
>
> No plans at the moment; we have the event history for the main repositories going back years.
How does someone outside of Kitware talk to this robot 🤖 or access this record?
My main complaint/question really lies here: where is this event history? is this backed up somewhere independently hosted or accessible?
> [@berk.geveci](#):
>
> - We are actively considering moving some of the hosting functionality to Github.
Don’t take my complaints here as saying “Please move to GitHub!”… While I’d love to see VTK on GitHub simply to be able to dynamically link PyVista and VTK issues/pull requests, I’m not going to pretend it’s the most reliable or best solution here.
---
### Author:  [@Matthew\_Woehlke](https://discourse.vtk.org/u/Matthew_Woehlke)
#### Post date: [September 15, 2026, 6:53pm UTC](https://discourse.vtk.org/t/gitlab-availability-and-preservation-of-vtk-s-community-history/16533/8 "2026-09-15T18:53:27Z")
> [@banesullivan](#):
>
> The point is not that large cloud hosted services are infallible… my point is that reliability, operational transparency, and independent preservation are ~solved engineering problems there (and they allocating immense resources to these challenges)
…and that is **exactly** my point. They aren’t. There is no more guarantee that those services will exist tomorrow than there is that Kitware will exist tomorrow. The difference is that Kitware and VTK have significant interests in each other’s continued existence. Even if they’re being paid for hosting, I don’t see GitLab/GitHub having the same level of motivation that Kitware has. The recent Iron Mountain incident is a reminder of the unreliability of cloud providers.
> [@banesullivan](#):
>
> [Kitware] has limited … public commitments to ensuring the posterity of the project
I don’t know offhand about _public_ commitments; you may have a point there. I _do_ know that Kitware has significant interest in VTK; more than any cloud provider you can name is likely to have.
You also mentioned other organizations seeking to preserve GitLab/GitHub repositories. Why do they not also seek to preserve kitware.gitlab? Considering the importance of CMake, especially, it seems like they should. I would guess (again, speaking personally and not on behalf of my employer) that Kitware is more than willing to assist with said preservation.
> [@banesullivan](#):
>
> Kitware has made any external effort to archive the project very difficult
> **[Wikipedian Protester](https://xkcd.com/285/)**
I don’t know the technical details of which endpoints are affected, but my impression is that they mostly aren’t ones that are critical for _archiving_. (As per Ben’s note, no legitimate archivist is going to pester the server to generate information that can be obtained from a local clone.) Also, I don’t see why a login requirement is an issue for a legitimate archivist. Again, I would guess that Kitware is willing to work with _legitimate_ archivists to the extent it is even necessary. If you are aware of _actual_ archival difficulties, it would be helpful to share those. Otherwise this feels like FUD.
Anyway, the underlying cause of the service problems is scrapers who don’t care how their actions impact the site’s integrity. _Those_ are the entities who are the proper targets of your ire.
---
### Author:  [@banesullivan](https://discourse.vtk.org/u/banesullivan)
#### Post date: [September 15, 2026, 7:02pm UTC](https://discourse.vtk.org/t/gitlab-availability-and-preservation-of-vtk-s-community-history/16533/9 "2026-09-15T19:02:03Z")
Going to take a moment to pause here because I think I am failing to properly get my point across.
A lot of my concern lies on the assumption that [gitlab.kitware.com](http://gitlab.kitware.com) is self-hosted, on-prem at Kitware HQ’s office? Is that correct or incorrect?
---
### Author:  [@jamesobutler](https://discourse.vtk.org/u/jamesobutler)
#### Post date: [September 16, 2026, 11:41am UTC](https://discourse.vtk.org/t/gitlab-availability-and-preservation-of-vtk-s-community-history/16533/10 "2026-09-16T11:41:30Z")
I would love to see VTK on GitHub’s cloud hosted servers along with the majority of other large open-source projects for the most convenient cross-referencing capabilities. GitHub for example feels a bit like a “too-big-to-fail” type situation (acknowledging parallels to the 2008 financial crisis).
Is Kitware’s own GitLab instance partially due to the United States Government - Department of Defense work that it does? If so, could the hosting/compliance needs of that work be separated from the fully public open-source software work? Where not everything would need to be on Kitware’s own GitLab instance? It seems like Kitware - Clifton, NY are primarily involved in the projects on the Kitware GitLab while Kitware - Carrboro, NC are primarily involved in projects on Kitware/KitwareMedical’s organizations on GitHub.
---
### Author:  [@ben.boeckel](https://discourse.vtk.org/u/ben.boeckel)
#### Post date: [September 16, 2026, 12:44pm UTC](https://discourse.vtk.org/t/gitlab-availability-and-preservation-of-vtk-s-community-history/16533/11 "2026-09-16T12:44:00Z")
So there are a technical issues with GitHub in my eyes:
- The CI configuraion is considerably worse with GHA compared to GitLab-CI. Not to mention what it would take for us to migrate our setup.
- GitHub forces a single-level organization level (we use nested orgs on `gitlab.kitware.com` and that’s _beyond_ the “kitware” org that is implicit on the instance, so we lose a lot of flexibility there.
- We need GitLab instances at Kitware _anyways_, so it’s not like our sysadmin obligations change that much. Granted the `gitlab.kitware.com` instance is a large chunk of maintenance burden, I don’t think it’d cut the time in half.
On a personal level, I find GitHub’s review experience to be…subpar overall and considerably worse compared to GitLab (and no, things like Reviewable do not help; the problems are baked into the data model and permissions). Considering how long some outstanding issues have been open, it just isn’t a priority at GitHub to resolve them either.
The push of Copilot everywhere is also extremely obnoxious. Coupled with the “but AI is just making so much more traffic for us” feels like marketing outrunning the engineering department there.
---
### Author:  [@ben.boeckel](https://discourse.vtk.org/u/ben.boeckel)
#### Post date: [September 16, 2026, 1:34pm UTC](https://discourse.vtk.org/t/gitlab-availability-and-preservation-of-vtk-s-community-history/16533/12 "2026-09-16T13:34:32Z")
> [@banesullivan](#):
>
> How does someone outside of Kitware talk to this robot 🤖 or access this record?
>
> My main complaint/question really lies here: where is this event history? is this backed up somewhere independently hosted or accessible?
It’s internal; it contains the names of repositories intended to be secret, so it cannot be made publicly available. It is also backed up.
---
### Author:  [@Matthew\_Woehlke](https://discourse.vtk.org/u/Matthew_Woehlke)
#### Post date: [September 16, 2026, 3:31pm UTC](https://discourse.vtk.org/t/gitlab-availability-and-preservation-of-vtk-s-community-history/16533/13 "2026-09-16T15:31:27Z")
> [@jamesobutler](#):
>
> I would love to see VTK on GitHub … for the most convenient cross-referencing capabilities.
This is actually one of the advantages to kitware.gitlab, at least for Kitware. It allows integration of public and non-public repositories (the latter of which would be difficult if not impossible to host elsewhere) that wouldn’t be possible with separate hosts.
* * *
Of the original questions, I feel like “is there a backup with another organization?” is the most interesting. Is there? If not, why not? I don’t think this should be entirely on Kitware to arrange, however, since it requires another organization willing to maintain those archives.
That said, it appears the _repositories_ are already preserved by Software Heritage. It appears, however, that SH archives _only_ the repositories, not other content such as Work Items. (Which makes me wonder who, if anyone, _is_ archiving that content, or if all that content would be lost if GitHub disappears.)
---
### Author:  [@jamesobutler](https://discourse.vtk.org/u/jamesobutler)
#### Post date: [September 16, 2026, 3:49pm UTC](https://discourse.vtk.org/t/gitlab-availability-and-preservation-of-vtk-s-community-history/16533/14 "2026-09-16T15:49:33Z")
> [@ben.boeckel](#):
>
> - GitHub forces a single-level organization level (we use nested orgs on `gitlab.kitware.com` and that’s _beyond_ the “kitware” org that is implicit on the instance, so we lose a lot of flexibility there.
GitHub supports managing multiple GitHub organizations as part of a single GitHub Enterprise organization. See [managing organizations in your enterprise](https://docs.github.com/en/enterprise-cloud@latest/admin/managing-accounts-and-repositories/managing-organizations-in-your-enterprise). There are a lot of permissions controls and enterprise wide rulesets versus organization level rulesets versus repository rulesets. If you haven’t had a look at the recent capabilities, there are many new things that have changed in the past few years.
> [@ben.boeckel](#):
>
> - We need GitLab instances at Kitware _anyways_, so it’s not like our sysadmin obligations change that much. Granted the `gitlab.kitware.com` instance is a large chunk of maintenance burden, I don’t think it’d cut the time in half.
Moving VTK off Kitware’s gitlab instance is not so much trying to remove the sysadmin duties, but more so letting Microsoft or another big company handle the defense against DDoS or other massive traffic influxes to keep the repository available to the public rather than relying on the arguably smaller Kitware resources to defend against the same attacks.
> [@Matthew\_Woehlke](#):
>
> This is actually one of the advantages to kitware.gitlab, at least for Kitware. It allows integration of public and non-public repositories (the latter of which would be difficult if not impossible to host elsewhere) that wouldn’t be possible with separate hosts.
Kitware seems to already support public and non-public repositories through it’s GitHub organization. In terms of the Kitware supported open-source technologies ([https://www.kitware.com/open-source/](https://www.kitware.com/open-source/)), there are already cases of upstream repos being on GitHub (as seen below). Transitioning VTK to GitHub would take a bit of work, but in terms of Kitware working in GitHub - that seems to already be working well. VTK would then join the mass of other open-source projects already on GitHub rather than GitLab/Bitbucket/sourceforge/etc.
[3D Slicer](https://github.com/slicer/slicer)
[Explainable AI Toolkit (XAITK)](https://github.com/XAITK/xaitk-saliency)
[Girder](https://github.com/girder/girder)
[HistomicsTK](https://github.com/digitalslidearchive/histomicstk)
[TeleSculptor](https://github.com/kitware/TeleSculptor)
[The Insight Toolkit (ITK)](https://github.com/insightsoftwareconsortium/itk)
[tomviz](https://github.com/OpenChemistry/tomviz)
[trame](https://github.com/kitware/trame)
~~[Kwiver](https://github.com/Kitware/kwiver)~~
---
### Author:  [@Matthew\_Woehlke](https://discourse.vtk.org/u/Matthew_Woehlke)
#### Post date: [September 16, 2026, 4:07pm UTC](https://discourse.vtk.org/t/gitlab-availability-and-preservation-of-vtk-s-community-history/16533/15 "2026-09-16T16:07:00Z")
Of that list, I know for certain that KWIVER GitHub is a mirror and not the primary repository.
---
### Author:  [@ben.boeckel](https://discourse.vtk.org/u/ben.boeckel)
#### Post date: [September 16, 2026, 4:20pm UTC](https://discourse.vtk.org/t/gitlab-availability-and-preservation-of-vtk-s-community-history/16533/16 "2026-09-16T16:20:47Z")
> [@jamesobutler](#):
>
> Transitioning VTK to GitHub would take a bit of work, but in terms of Kitware working in GitHub - that seems to already be working well. VTK would then join the mass of other open-source projects already on GitHub rather than GitLab/Bitbucket/sourceforge/etc.
Those projects had their own discussions when we migrated from prior solutions to what was available then. Personally, “everyone else does it” isn’t very compelling. Plus, given the problems GitHub _has_ been having, there’s been a lot of activity in the software forge area lately. If we’re going to migrate, I’d rather see what else is out there before moving horizontally to GitHub which is, largely, similar in feature set to GitLab.
---
### Author:  [@berk.geveci](https://discourse.vtk.org/u/berk.geveci)
#### Post date: [September 16, 2026, 4:29pm UTC](https://discourse.vtk.org/t/gitlab-availability-and-preservation-of-vtk-s-community-history/16533/17 "2026-09-16T16:29:09Z")
This thread turned into a self-hosted/gitlab/github argument so I created a new thread that aims to answer Bane’s questions specifically.
---
### Author:  [@jamesobutler](https://discourse.vtk.org/u/jamesobutler)
#### Post date: [September 16, 2026, 5:22pm UTC](https://discourse.vtk.org/t/gitlab-availability-and-preservation-of-vtk-s-community-history/16533/18 "2026-09-16T17:22:15Z")
> [@ben.boeckel](#):
>
> Plus, given the problems GitHub _has_ been having
> [@banesullivan](#):
>
> GitHub and GitLab publish public status histories, incident reports, and availability commitments. GitLab documents 24/7 infrastructure monitoring and a 99.9% availability commitment for covered SaaS services, including issues, merge requests, and Git operations ([status](https://status.gitlab.com/), [availability policy](https://handbook.gitlab.com/handbook/engineering/infrastructure-platforms/service-level-agreement/)). GitHub likewise publishes incident histories and detailed availability reports ([status](https://www.githubstatus.com/), [availability report](https://github.blog/news-insights/company-news/github-availability-report-june-2026/)).
[https://status.gitlab.com/](https://status.gitlab.com/)
[https://www.githubstatus.com/](https://www.githubstatus.com/)
Does Kitware’s gitlab instance have a similar status history to make it publicly possible to compare uptime or other metrics against GitLab hosted resources or GitHub hosted resources?
---
### Author:  [@ben.boeckel](https://discourse.vtk.org/u/ben.boeckel)
#### Post date: [September 16, 2026, 5:47pm UTC](https://discourse.vtk.org/t/gitlab-availability-and-preservation-of-vtk-s-community-history/16533/19 "2026-09-16T17:47:20Z")
No, I don’t think we do. Even so, I suspect it matters where it is measured from given that mitigations sometimes end up involving absolute blocks on “bad” IP ranges. In any case, the vast majority of issues is either “another influx of bot traffic” or “upgrade in progress” (for which banners are up at least a day in advance).
Most of my development is on Kitware’s GitLab and I’ve not thought it’s gotten to the point of wanting to move it anywhere else. But I also am aware that the causes are mostly external and some planned improvements which should help that are underway (but been slow due to the limited availability of hardware).
Other than AI scrapers disappearing from the face of the Earth, my preferred resolutions:
1. wait for the new hardware to be deployed and see how much that improves things
2. work on improving GitLab performance
3. investigate a high-availability deployment of GitLab (IIUC, redundancy and fail-overs)
4. consider moving the GitLab instance into the cloud behind better-than-Anubis DDoS protection
Migrating forges is after that and even then, I expect there to be better competition than GitHub (e.g., issues and reviews stored in-repo rather than on a central DB) which _would_ be a step-up from GitLab.
---
### Author:  [@will.schroeder](https://discourse.vtk.org/u/will.schroeder)
#### Post date: [September 16, 2026, 5:37pm UTC](https://discourse.vtk.org/t/gitlab-availability-and-preservation-of-vtk-s-community-history/16533/20 "2026-09-16T17:37:45Z")
Here’s one statistic that I like: Kitware has successfully hosted VTK for 28 years 🙂.
There were a couple of dicey years before that when I hosted the CVS repository on my Sun workstation at RPI (after the VTK textbook book came out in the mid 90’s). Probably before some of you were born…
[Next page](https://discourse.vtk.org/t/gitlab-availability-and-preservation-of-vtk-s-community-history/16533.md?page=2)