CodeFloe is a cloud-native Forgejo-based Git host with a focus on modern DevOps tooling and practices. It supports both public/private repositories and welcomes any kind of project licensing.

It aims to be an alternative to existing, proprietary(-managed) Git hosting platforms like GitHub, GitLab and others.

From a legal standpoint, CodeFloe is owned and managed by devXY, a DevOps and Data Science consultancy based in Switzerland. The owner of devXY is also the founder of CodeFloe. This structure was chosen primarily because operating a platform as a company is significantly simpler than establishing and maintaining a foundation, particularly in German-speaking countries where foundations involve considerable administrative overhead.

In practice, CodeFloe is run by a combination of devXY team members and various independent contributors who are passionate about supporting the platform. CodeFloe’s goal is to foster meaningful community participation and contributions, with the intention that such efforts are fairly compensated.

Yes and no.

The primary goal of CodeFloe is to offer a fast, transparent, and lightweight alternative to existing Git hosting platforms. Delivering this service incurs expenses for servers and storage, which are currently covered by devXY.

Ideally, CodeFloe will become self-sustaining over time through donations and optional paid tiers—these paid options are intended solely to offset the additional resource usage of power users. CodeFloe will never lock specific platform features behind a paid tier like other competitors do.

If there are surplus funds after covering all infrastructure costs, the intention is to distribute these among those actively maintaining the platform, preferably through a transparent process, provided it doesn’t create excessive administrative work. At this stage, there are no definitive rules for how such distributions would be handled; the specifics will be determined by the responsible parties if and when the situation arises.

In summary, while CodeFloe can generate a profit, its main objective is to cover its operational costs. Given the ongoing growth in storage and compute (CI/CD) demands, these costs are expected to consume the majority of available funds.

CodeFloe is a public platform, hence everyone can access the public data (repos, packages).
Private repos can be accessed by CodeFloe admins, due to the nature of the underlying software. There is no detailed audit logged for such accesses. You need to trust the admins of the platform in this regard. Note: Do not store sensitive secrets or other data that you absolutely do not want to be seen by anyone. The only way to ensure this is to not use a public Git hosting platform.

In contrast to other platforms though, CodeFloe will not use the data stored to improve “internal processes” or train AI models.

Furthermore, CodeFloe is hosted in Europe, and hence protected by the GDPR and other European-based data protection laws.

CodeFloe will not actively block common web crawlers from indexing the content, unless these are imposing substantial load onto the platform. CodeFloe repos are meant to be found when doing web searches and aim to provide similar public promotion capabilities as GitHub and friends do.

Absolutely—the more, the merrier!
CodeFloe is designed to be an open and community-driven platform, emphasizing both transparency and active participation from its users.

There are many ways to contribute: you can submit code directly to CodeFloe’s infrastructure, help moderate the Forum, or take responsibility for specific areas like monitoring or documentation. In general, contributions are encouraged and appreciated across all aspects of the platform.

However, as with any project of this scale, please note that not all contributions can be guaranteed acceptance or deployment. The maintainers of each project area retain the final say on what gets incorporated into production.

Several other names were considered initially.
However, most were either unavailable as .com domains or posed potential trademark issues (for example, any service with “Git” in its name now violates the Git trademark).

Securing a suitable .com domain in 2025 is incredibly difficult, particularly if you want it to:

• sound appealing when spoken aloud,
• offer potential for a memorable icon,
• and maintain some relevance to the service itself.

The word “floe” refers to an ice floe.
And yes, the current icon does resemble an ice cube more than an ice floe.
There were early attempts at designing a floe-inspired logo, but none of the sketches felt quite right in the end.

Unlike many competitors, CodeFloe is committed to complete transparency regarding its infrastructure.

The platform is managed using OpenTofu and Ansible, with all configuration files openly available in the codefloe/infrastructure-as-code repository.

CodeFloe employs a hybrid, cloud-native approach combined with self-hosted applications.
This means that while cloud resources—both virtual machines and bare-metal servers—are utilized, all applications themselves are self-hosted and distributed across these servers as needed.
This setup leverages the flexibility and reliability of the cloud (eliminating the need for direct hardware management) while allowing for seamless scaling as the platform grows.

Since the infrastructure is continuously evolving, the best way to stay updated is by following the linked repository.

CodeFloe consists of the following data elements:

• Repository data
• Database
• Packages
• Attachments/Avatars

All of these are backed up on an hourly/daily base to multiple backup locations and stored there for up to 30 days. In the case of data corruption or hardware failures, all of the above can be restored with a maximum data loss of up to one hour.

As Forgejo is currently not yet capable of running in cluster mode (i.e. multiple instances on different servers with standalone data sources), the worst case event would be a hardware failure on the server running Forgejo.
Once Forgejo is HA-capable, a distributed, mirrored setup will be targeted. This likely also means duplicating the repository data X times, which will require adequate funds at this point in time to do so.

The (Postgres) database is running in high-availability mode on (at least) three nodes. This allows for proper load-balancing and failover capabilities in case of hardware failures.

As previously mentioned, CodeFloe currently operates from a single location in Germany. This means that the farther a user is from this server, the higher the latency (i.e., connection time) they may experience.

Since Forgejo does not yet support cluster mode and the platform is still in its early stages, implementing a multi-region setup is not practical at this time.
Such a configuration would be complex to establish and maintain, while only offering marginal improvements—typically just a few (hundred) milliseconds saved per connection.
However, this option may be revisited in the future if the platform grows to a scale that warrants it.

To ensure a responsive experience for users outside Europe, CodeFloe makes extensive use of caching and has enabled HTTP/3, which significantly reduces latency for distant connections.

We did some tests with VNC-forwarded browsers in US West and Asia. After enabling http3, the latency was quite acceptable and roughly comparable to how GitHub and GitLab feel when navigating. You will not feel the snappiness as when connecting from Europe, but we are positive that CodeFloe is properly usable from all around the world!

One of the primary goals in building the platform was to ensure it remains fast.
While achieving good performance is relatively straightforward with low traffic, our aim is to maintain this responsiveness even as usage grows.

The architectural choices were shaped by extensive experience with Gitea/Forgejo—the founder has been a long-time contributor and maintainer of these projects, providing deep insight into their inner workings.

Three key components have the greatest impact on performance:

• Database:
  The database operates in high-availability (HA) mode, using a split-routing approach for read and write operations. It is hosted on-premises and connected to Forgejo via a local network.

• Reverse Proxy:
  The reverse proxy (HAProxy) has been carefully optimized for maximum performance, including a custom-built version with HTTP/3 support.

• Disk Speed:
  Repository files are served from NVMe disks, which is essential for delivering fast responses to file queries. Avoiding network file shares and relying on high-performance NVMe storage is critical. While the current setup already performs well, there is still potential for further improvements, such as upgrading to larger and faster disks on bare-metal servers.

Storage quotas are in place for every user/organization.
They can be viewed in the respective user/org settings under “Storage Overview”.

No repository limits exist. Each user/org has a 5 GB (free) storage limit for Git content by default.

As storage is expensive and hard to reduce on the admin side once it exists, the quotas are somewhat small.
Yet they should be large enough to host dozens/hundreds of repos and store properly sized packages.
If more space is needed, limits can be increased against an adequate financial contribution (relative to the request). Contact us at storage@codefloe.com.

CodeFloe provides two CI/CD options:

• Crow CI
• Forgejo Actions/Act

Both apps have a substantially different approach to CI/CD:

• Crow CI is a standalone app providing a central dashboard for all CI/CD pipelines/workflows. It is a FOSS project written in Go & Vue.js and maintained by the same people which founded CodeFloe.
  Crow has a container-only approach, i.e. all builds are executed in containers.
• Actions is similar to GitHub Actions and directly integrated into the CodeFloe UI. It does not have a central entrypoint but must be managed on a per-repo basis. It can run directly on the host and make use of containers.

Users of CodeFloe can choose which app they like most

Crow CI integrates seamlessly into the CodeFloe software stack and philosophy:
As a FOSS project with lots of potential, its adoption within a platform like this helps increase its visibility and user base, leading to more user feedback and, ultimately, long-term improvements to the application.

Unlike many other CI/CD solutions, Crow CI is lightweight and provider-agnostic, i.e. it can be used with any popular Git platform. It can optionally be deployed on private Git platforms, allowing for an easy re-use of existing workflow definitions.

The following resource limits are in effect:

• Up to 4 CPU cores (per workflow/job/container)
• Up to 3 GB memory (per workflow/job/container)
• No limit for the total amount of workflows/jobs per time and user (due to technical limitations)

These limits should allow to execute almost all common workflows of software development while at the same time preventing potential abuse of freely provided resources.
We hope to be able to keep it like this. Yet this only possible if users do not aim to push its boundaries and stay responsible for their own resource usage.
If it turns out that this is not practicable, we may rethink these limits to protect the platform and its users.

If the resources are not enough for your needs and you don’t/can’t use private runners, you can reach out to us through contact@codefloe.com and we can provision private runners for you that match your resource needs.

Currently, builds are running on the following servers:

To route builds to specific architectures:

Crow CI:

labels:
  platform: linux/amd64

Actions:

jobs:
  <name>:
    runs-on: arch=arm64

CodeFloe’s primary goal is to sustain itself through donations.
In addition, there will be paid tiers available—not to unlock extra features, but simply to accommodate users who require greater resources (such as additional storage or compute power).

The guiding philosophy is: “only charge for what generates actual costs.”
We believe it should be possible to operate a public service without restricting features or requiring payment to access them. If users appreciate the platform, they can choose to support it through donations, rather than being obligated to pay just to use the service.

To be completely honest: only time will tell
There is always a risk that costs—especially for disk storage and bandwidth—could outpace the donations received.
devXY will do its best to cover these expenses within reasonable limits and will keep the community informed if any concerning trends arise.

You could describe this approach as “semi-professional,” and that would be fair.
However, devXY is deeply committed to FOSS principles and is intentionally trying to do things differently. Ultimately, with donations as the main support mechanism, the platform’s success and sustainability will depend on the community’s engagement and contributions.

In the unlikely event that the gap between platform expenses and incoming funds continues to widen, CodeFloe may ultimately be forced to shut down.
However, there are several measures that would be taken before reaching that point:

• Temporarily pausing new user registrations
• Proactively informing existing users about the situation
• Providing a clear timeline outlining anticipated changes and potential solutions

If these steps do not lead to a sustainable outcome, it would indicate that the platform is not financially viable.
In that case, users would be encouraged to migrate their code to alternative platforms.