97
StatusGator last checked the status of Codeberg on July 31, 2026 at 7:57 PM CEST and the service was operational. There have been 83 user-submitted reports of outages in the past 24 hours, but the outage is now resolved.
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 31 Jul 2026
97 points (100.0% liked)
Programming
27953 readers
106 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 3 years ago
MODERATORS
popularity is going to love them very very hard.
they need someone with a highlevel of resiliency experience. code hosting isnt normal web traffic.
i am curious what its hosted on
https://docs.codeberg.org/getting-started/faq/#where-is-codeberg-hosted
well, that answers that question. they need to figure out a better solution.
Codeberg runs on Forgejo which is a fork of Gitea.
I'm running Forgejo myself and am running into difficulties with High Availability. Many data files can be stored in S3 compatible interfaces, but the Git repos are stored as Git files on disk. That's hard to distribute across multiple hosts. Something like NFS seems to be prone corruption and Forgejo has to be able to lock.
An open issue on clustering : https://codeberg.org/forgejo/discussions/issues/259
Reading your comment, I immediately thought there must be an S3 FUSE wrapper out there, and quickly found this:
https://github.com/s3fs-fuse/s3fs-fuse
The problem is still concurrency. If the application, in this case the git CLI, is not thread-safe, then you could run into unsafe data mutations causing data corruption.
Imagine two pushes that come in around the same time. S3 doesn't have the locking mechanics you need to ensure that only one of those writes win and the other fails. You need to upload the individual commits (which can be isolated except in the case of multiple writes with a partial write), but then the branch and HEAD pointers have to be serialized. I've done a lot of work with distributed systems in AWS and my experience has always been to layer something like DynamoDB on-top of S3 to provide this.
My knowledge of at least one distributed Git system was that they had a fleet of Git data servers and a router on front. The router would fan it out to 3 or more data servers where each data server would store copies. But ultimately there's some application logic that is aware of the underlying filesystem and manages locking.
GitHub shares some of their architecture here: https://github.blog/engineering/infrastructure/stretching-spokes/