Launching CodeFloe

I am happy to announce the launch of CodeFloe, a public Git forge designed to combine the best of modern infrastructure with a transparent deployment process. You can find CodeFloe at codefloe.com, where it’s ready to host your projects, whether they’re private, public, commercial, or open source.

 Why (yet) another Git instance?

The landscape of Git forges is broad, with each platform offering its own philosophy and set of trade-offs. GitHub is the default for many, but namespace scarcity and corporate policies can be limiting. GitLab provides powerful features, but its user interface often makes even simple tasks feel cumbersome. Codeberg, meanwhile, is a fantastic FOSS-focused alternative, but its strict content policies and infrastructure limitations can make it less suitable for commercial or hybrid projects.

 Finding a home for devXY

My own journey through these platforms began when I launched devXY about a year ago and quickly discovered how difficult it can be to secure a consistent namespace across all the major platform domains needed for an IT company: Git, container storage, web, social media, uniqueness for web discovery, etc. During the name finding process, I saw that the devXY namespace on GitHub was already taken by an inactive account¹, which led me to try GitLab next, as I needed an instance to host all my public efforts². However, after several months, I found GitLab’s navigation so frustrating that it became a barrier to productivity, despite its useful subgroup feature.

 Is it Codeberg?

Looking for alternatives, I turned to Codeberg. While it seemed like a natural fit, I was not sure at the beginning whether Codeberg’s Terms of Use would allow me to place a commercial organization account there - even for a company like devXY, which is mainly operating in the FOSS space. Companies usually need private repos for one reason or another, be it for starting something new which is not yet ready to be shown to the public or to prevent an idea from being copied at an early stage. I acknowledge that I might have not read Codeberg’s Terms of Use thoroughly enough (at that time): Right now (and maybe even back then), Codeberg’s docs state:

Private repositories are only allowed for things required for FLOSS projects, like storing secrets, team-internal discussions or hiding projects from the public until they’re ready for usage and/or contribution.

On top of that, I could also have asked them directly and clarified the situation, which I did not. All of this was happening at the same time when Codeberg faced a long period of performance issues (a mix of internal technical issues and external attacks) in mid-to-late 2024. I came to the conclusion in sum, I don’t want to place my main company org at Codeberg for the time being. Eventually I found myself stuck: for the time being, I kept devXY’s public projects on GitLab while thinking about the next steps.

Prior to this period, I was already active in trying to help Codeberg improve its performance and user experience. However, given existing structures and processes bundled with technical philosophies within Codeberg, this did not turn out (too) successful. Because these discussions/efforts were fundamental to the founding of CodeFloe, I want to elaborate a bit more on these in the next section.

 Takeaways from my time with Codeberg

I want to be clear from the outset that Codeberg is a fantastic initiative and deserves unconditional support in the world of public Git forges. As a member of Codeberg’s Core team for nearly two years, I’ve seen both the strengths and the challenges of running a public Git forge. Codeberg has led the way in providing a donation-based, privacy-respecting Forgejo instance, and its commitment to user privacy and open-source values is second to none.

However, during the last two years I also observed systemic challenges within Codeberg which I (personally) believe should be addressed differently. To understand the bigger picture better, I want to elaborate on these as brief as possible in the next sections.

 Architecture

The single-host architecture³, where all services run on one large server divided into LXC containers, creates a significant single point of failure. Even if sub-services are running somewhat isolated, they still run on the same host. Significant load from one service can substantially impact the performance of other services, depending on the share of this service to the overall host resources. When hardware issues occur, the entire platform can go offline, requiring physical intervention.

 Self-managed storage

The (legacy)⁴ BTRFS-backed disk setup on the (primary) colocation server has proven difficult to be managed at scale by the people in charge (with me personally taking a read-only approach in the discusssions). This is likely not surprising to anyone and I am not at all sure if I would have faced fewer issues myself. In the end, disk-related (hardware & software) management is hard, especially for a production environment which aims to be online 24/7. Yet, doing so is a choice and comes with pros and cons.

 Infrastructure as Code

Another challenge has been the reliance on (semi-)manual processes over automation. This is also the point which depressed me the most from a process-based perspective. I realized over time that our philosophies on this topic are entirely different.

While there have been (several) attempts to introduce Ansible (both historically (from others) and from me personally in recent times), most of the infrastructure is still managed through manual steps and custom scripts. This approach does not scale well, is hard to automate, hard to get into in the first place as a new contributor and does not have any loggable/RBAC-based deployment mechanisms (besides the point that script changes are logged via Git). Tools like Ansible and friends were developed specifically to address such issues and move away from custom (bash) scripts to a more structured and maintainable approach for managing infrastructure.

 CI/CD

Next: CI/CD.

Repository cloning can (often) take close or even more than ten seconds due to the use of HDD-based storage for the agents. CPUs are shared with other services, possibly resulting in limited performance. There are no arm64 runners as of today. A manual approval process is in effect to use CI in the first place, which is semi-manual⁵. Even though users are asked to outline their resource needs and promise to use FLOSS licenses, there are currently no enforced resource limits, which sometimes leads to resource exhaustion and impacts everyone’s builds⁶. License checks for approved projects do not happen in a systematic manner after the initial approval; detection of violations usually happen at random/by chance.

 The association structure

Finally, the association structure of Codeberg, while fostering community ownership, makes it (very) difficult to implement rapid changes. While it depends on your mindset whether this is a good thing or not, I am team “progressive” and enjoy updating early and moving (reasonably) “fast”.

Decisions in Codeberg are slow and, depending on the context, sometimes even require a proposal that must be voted on, to follow the legal association structure. Yet on top, responsibilities within the association and project itself are often unclear, leading to missed responses, confusion on how is actually able to make a decision for task X and eventually results in a stale result.

Distribution of funds is non-trivial as any spending for a service or good must directly contribute and aligned with the (legal) scope of the association. While this might sound like an issue in the first place, this leads to practical issues in daily practice, when facing tax-based regulation checks and more throughout the lifetime of an assocation⁷.

The commitment to self-hosted hardware limits architectural flexibility, at least in the way it is currently applied in practice.

I can understand the general motivation for an association structure and I am not claiming it to be a bad choice for a project such as Codeberg. However, I would wish that the whole entity would be more flexible and less bound by buerocratic regulations, for so many reasons and at so many levels. Doing voluntary work should be fun, definitely most of the time. It shouldn’t be(come) a torture for the people in charge.

 Introducing CodeFloe: a fresh approach to a Forgejo-based public instance

CodeFloe is the result of these lessons learned/observed, and aims to do the mentioned points differently. Rather than relying on a single server, CodeFloe distributes its services across multiple virtual machines. The database runs in high-availability mode with read/write splitting⁸, and the Git service is isolated and optimized for disk and network performance. Assets like packages, images, and backups are stored on S3-compatible storage, and the platform uses a state-of-the-art HTTP3-enabled proxy: HAProxy compiled against WolfSSL. This architecture allows CodeFloe to scale dynamically, adding storage or compute power as needed without worrying about hardware failures or shortages.

The CI/CD experience on CodeFloe is designed to be fast and frustration-free. With SSD/NVME-backed runners, repository clones happen in seconds. Both amd64 and arm64 runners are available, making it easy to build for modern architectures. Every user gets a generous free tier, 3GB of RAM and 4 CPUs per container, with no need for manual approvals and no artificial limits on parallel jobs. (If your project needs more, you can use private runners or managed agents provided by CodeFloe.) The goal is simple: every project should be able to run tests and lints in a fast manner without unnecessary barriers, as I consider this one of the most important aspects of a code forge platform.

Governance is another area where CodeFloe takes a different approach. The platform is legally operated through devXY, my company, which allows for quick decision-making and investment without bureaucratic overhead. However, CodeFloe fundamentally aims to be a community platform without the need for profit. There is a Discourse forum at forum.codefloe.com for open discussion and feedback. All operations are transparent: every change is publicly tracked, and every platform contribution is accounted for. Community contributions are welcome. The infrastructure is managed using modern GitOps principles (OpenTofu, Ansible, CI/CD) to ensure consistency and reviewability. See also docs.codefloe.com for more information on the technical setup.

 Sustainability

From the outset, I am personally fully funding CodeFloe (at the start) because I believe in its value and also use it for my own projects. But the platform’s long-term sustainability will depend on community support through LiberaPay. I believe in donation-based funding having the power to sustain CodeFloe’s operational costs because of CodeFloe’s efficient, cloud-native architecture, which keeps costs low and allows resources to be scaled precisely to demand. Every contribution is transparent, and as the platform grows, funds can be distributed fairly to those who help maintain and improve the service.

The main costs for CodeFloe are CI runners and storage. By leveraging cloud infrastructure efficiently and encouraging community support, we can provide a superior service at a fraction of the traditional cost of other similar platforms.

 Join CodeFloe

Getting started with CodeFloe is simple. You can create your account at https://codefloe.com, import your projects, and immediately take advantage of fast CI/CD with both amd64 and arm64 runners. The platform supports all standard Git workflows, so you can migrate seamlessly from your current forge. If you have feedback or want to help shape the future of the platform, join the discussion at https://forum.codefloe.com. There’s no catch. CodeFloe doesn’t need to make a profit. My goal is to create a sustainable and transparent code platform for the community. Everything else is bonus and purely optional.

If you believe in a Git forge that combines modern infrastructure with community values, I invite you to use CodeFloe for your projects, contribute via LiberaPay, participate in the forum, and help spread the word. I truly believe that together, we can build a sustainable, high-performance Git forge that serves everyone, from individual developers to companies, from FOSS projects to commercial ventures.