GitLab is a free devops solution for hosting a git repository, managing issues, contaienrs and packages, ci/cd and much more.
Repositories itself should not contain large files like ZIP archives or binaries, which are not code-related or frequently change. If you need to store data like this inside a repository, please use LFS.
LFS is a feature of git, allowing tracking of large binary files in a more scaleway way and keeping them out of the repo itself to allow fast cloning and working with git. Tracking large files without LFS usually slows down working with git.
You should especially consider this if your repo already uses more than 1 Gigabyte of storage or you intend to upload files of >100 MB to the repo.
The instance has configured instance runners, allowing you to execute CI jobs without needing to spin up your own runner. They are free to use and supplied under fair-use. Please don't abuse them and please set up your own runners, if you plan on making extensive use of CI/CD.
In terms of security, these runners use containers to seperate jobs from the host and keep everyone in their own little box, but please be aware that containers are not totally secure and there have been reports of security researchers being able to escape containers, so these shared runners should be treated as low-security and only been given trivial or easily revokeable secrets.
When changing GitLab's configuration or updating the instance, GitLab will be down for a minimum of a few minutes. Receiving a 502 - Bad Gateway error for a few minutes is quite normal and expected, GitLab just takes a long time to fully restart/reconfigure.
This GitLab is connected to our Mattermost instance, allowing you create a team for a project and have text-based discussions and planning. See below for more infos on the service.
In case an anime girl has denied you access, you have been blocked by Anubis. It is a similar thing to what you sometimes see with Cloudflared websites, a protection against bots pretending to be human. The way it works is that it gives you a small task + processes some statistics about your client to determine if you are a real person infront of the computer.
If you have been blocked, please make sure that you have no extensions blocking Javascript or changing your browser's User-Agent. If you still experience issues, take a look at the Anubis issue tracker to see if someone might have a similar problem. Also, these browser extensions are known to break Anubis.

There has been a tremendous influx of bots scraping the site, and due to it beeing a Git server, there are endless possibilities to query the server, meaning an endless supply of possible requests the bots can and do make. Before GitLab, I was using Gitea and that instance sometimes became literally unuseable as it sometimes got DDoSed by these bots. At some point the instance was restarting every 10 minutes because bots would make so many requests that the server ran out of memory and killed Gitea. I really do not want to experience something like that with my GitLab instance, hence the bot protection.
Anubis only gets involved when a requests appears to come from a real browsers. Good bots don't hide the fact that they are bots, identifying themselves clearly and behaving well. Anubis generally lets normal bot requests through and also includes a whitelist for known-good bots to cause as little problems as possible.

Only if your browser identifies itself to the website as a real browser (which bad bots usually also do in order to bypass classic bot preventions (yes, very ironic)) will prompt Anubis to put that up to the test and challenges your browser to calculate a quick math problem, in order to proove that your browser is indeed fully functional and not just facade. Anubis then stores a cookie on your browser in order to let you through for the next few hours.

It is the mascot of the Anubis project and it is here to stay. You are on a .moe domain after all.