Codefloe Is a Professionally Hosted Public Git Forge | Hacker News Reader

Codefloe Is a Professionally Hosted Public Git Forge

codefloe.com

69 pointsjeremyjh50 comments

Being "professionally hosted" is not enough: You need a "cluefully developed" distributed git backend to be a GitHub competitor. Codeberg is already buckling despite being nowhere near GitHub's scale. When Codefloe gains more users/agents, it's going to suffer from the same fate since Forgejo/Gitea/Gogs just isn't a good foundation to build on top of.

What do you think makes it a bad foundation to build on?

See Cursor's recent blog post on launching a Github competitor, particularly the architectural history.

Right...check the vibe coded slob pile for reference...

That’s a great blog post, lots of details, helpful animations, historical context, and an interspersing of war stories.

https://cursor.com/blog/git-at-any-scale

Their primary storage medium is block storage which is quite expensive. Codeberg cited it, although post-hoc, in their decision to ban AI projects. GitLab runs (or ran) the large block storage based Git service I know of which is Gitaly.

If you want to achieve public service level traffic and cost then you pretty much need to find a way to leverage object storage.

Note that this assumes cloud-based. A rack full of hard drives is far cheaper per GB than either, even at 50% utilisation and 2x redundancy. (It would have to be! Amazon obviously wants to make a profit)

GitHub also uses block storage - its just git on NVME. The complicated part is the redundancy and ensuring consistency.

Cursor introduced an S3 WAL in their new system, Continuity. https://cursor.com/blog/git-at-any-scale

(founder of codefloe)

Codeberg is buckling because of old hardware and not-so-great operational devops processes. I am stating that as a former core member with access to these and the historic goals of changing something to the better. The underlying software is not the issue.

GitHub and GitLab were built on Ruby. The language behind this is much less suited to serve a platform with that many requests.

The hard part is the SRE engineering behind it and the option to potentially make tweaks in the underlying codebase when needed, to fix possible bottlenecks (most often it comes down to how SQL is being processed).

Free CI is what really is going to keep many on GitHub (Actions). Codeberg has Woodpecker CI requires a FOSS application to get approval to use limited free tier. CircleCI has a free tier also but doesn't look like official documentation for integrating with Forgejo.

Being able to produce x86_64/arm64 builds for macOS, Linux, and Windows for free is a minimum start to get movement to another provider IMHO. GitHub already does this.

They have free CI with pretty generous limits: Up to 4 CPU, 7 GB memory and no max build times. I don't think there is a public Windows or Mac runner. But I think this is where they could run into real issues if they get a lot of adoption without a lot of donations. It could get expensive fast.

How does GitHub prevent me from mining crypto on free CI?

I've ported a couple of repos to CodeFloe in the last few days, and so far, so good. Performance is similar to when I self-host Forgejo on a dedicated VPS where I'm the only user, which is super fast. And their built-in CI is pretty nice.

It's a huge contrast to Codeberg, which struggles with basic navigation of the web UI and every git push or pull takes 2-10s.

> Performance is similar to when I self-host Forgejo on a dedicated VPS where I'm the only user, which is super fast.

I don't mean to be negative, but that's probably because it's pretty much the same thing. Codefloe is tiny. Some quick counting shows it has a grand total of 1012 registered users, including bots, and 1416 public repositories of which the top 3 with the most stars (I know this is a mostly meaningless metric, but for scale) have 27, 13, and 8. It's too small to run into scaling issues.

They keep public records updated quarterly (neat!). Until June they had 774 users and 2090 repos: https://codefloe.com/codefloe/analytics/src/branch/main/repo...

(founder of codefloe)

Numbers are just one thing, what counts is the effective request traffic. We are just as large as we are and can't do anything about it ;)

The only thing we can influence is to stay fast from day to day, watch our disk and storage and adjust things if needed.

I am quite confident that we can take multiple tens of thousands, if not hundred of thousands of users (with the respective request ratio share of active and dead accounts) with our current hardware stack. We'll see how it goes when we eventually get there.

That’s an interesting question - it’s one thing to run an instance of forgejo for a limited user base and another to run at mass public scale.

How does someplace like a GitHub/Gitlab go it? Are user accounts or repos sharded across different servers? Is there a different underlying scaling system? If one wanted to run Forgejo “at scale” what would it really require, or does this need to be factored into the design from day one?

This recent post that made it to the front page talks a lot about approaches GitHub has taken over its history:

https://cursor.com/blog/git-at-any-scale

I ended up finding my own answer (after reading the above).

https://nesbitt.io/2026/02/26/git-in-postgres.html

Following another recent theme, the answer for Forgejo seems to be - just use Postgres.

That approach was mentioned in the Cursor article. If a KV cache like Redis is too slow for that to work with large repositories, I don't see how Postgres could possibly work.

I just use Github as a backup and use my own git repos as primary. Works really well. CI/CD is blazing fast as well. You don't need all these complicated actions flows and all that. Just write for yourself. And a missing feature is a short prompt away. Especially useful is that Github has a co-tenancy problem and an untrusted input problem. For your own company, you can build that more surgically. I wouldn't normally go on the build side of buy v build, but write-to-deploy duration minimization is a strong value of mine and with agents you really need that tight.

Seems good! I'd migrate some of my open source projects, but they utilize the public static page hosting features of GitLab and GitHub, since they are typescript libraries that are demonstrated in the browser, so I'm reluctant to upset that.

Codefloe has that feature (which isn't in stock Forgejo). But yes it might take a little bit of work to migrate to it.

(founder of codefloe)

We have a custom integration for "Pages" in partnership with statichost.eu. You'll get a fully provisioned static website (h3 enabled) in < 1m with the click of a button. Custom domains are supported. Effectively the same what GH Pages offer :)

See https://docs.codefloe.com/pages/

As far as I can tell; it's not EU. It's Switzerland. Which is a huge difference when you think about data protection and privacy.

---

Btw: If I try to open the website in a normal browser, I can't, because they have some kind of protection.

Its in Germany.

It's a Company in Switzerland that tell they host most of there stuff with Hetzner in Germany.

What makes this different than Codeberg?

Allowing heavily AI projects, from a glance.

Codeberg is for open source projects only. This is for anyone.

You can have private personal projects and even commercial/business projects. Codeberg does not want private personal projects.

"In no event shall CodeFloe or its suppliers be liable for any damages (including, without limitation, damages for loss of data or profit, or due to business interruption)"

So many fly-by-night "github replacements" popping up. Step 1, buy a hetzner dedi server from the auction for $100/mo. Step 2, install Forgejo. Step 3, ride the wave of anti-US, anti-big-corp senitment to get users onto your platform. Step 4, an HDD fails in your i9-13900k and you lose half of your users' data.

If you are going to offer hosting, you need to state what kind of guarantees around data protection you offer.

I think you're holding CodeFloe to an unreasonably high standard here. What SaaS vendors agree to financial guarantees if they lose user data or have an outage?

Here's GitHub's policy:

> We will not be liable for damages or losses arising from your use or inability to use the service or otherwise arising under this agreement.

https://docs.github.com/en/site-policy/github-terms/github-t...

Here's Atlassian's policy for BitBucket:

> 14. Limitations of Liability

> 14.1. Damages Waiver. Except for Excluded Claims or Special Claims, to the maximum extent permitted by Law, neither party will have any liability arising out of or related to this Agreement for any loss of use, lost data, lost profits, interruption of business or any indirect, special, incidental, reliance or consequential damages of any kind, even if informed of their possibility in advance.

https://www.atlassian.com/legal/atlassian-customer-agreement...

That is fair. This was just the only thing in their terms that I could find that made any mention in regards to data protection. If you are running a service like this, some kind of SLA should exist. I am less concerned with financial protections and more concerned with data protection.

> What SaaS vendors agree to financial guarantees if they lose user data or have an outage?

Lots of them. See, e.g., https://aws.amazon.com/compute/sla/

Now, they're not written in terms of compensatory or consequential damages, but you will be entitled to a service credit (which is a "financial guarantee" of sorts) if the conditions are met.

Private agreements frequently have these sorts of provisions as well. You need to be a pretty big or strategic customer to get those, though, and they're often paired hand-in-hand with long-term agreements with mandatory minimum spend.

Service credit is practically worthless. Oh we deleted all your data? Here's a month of free hosting for the data you don't have.

Has that actually happened?

At the very least, the main guy behind this is pat-s who was originally a WoodpeckerCI dev and has been in and around Codeberg/Forgejo/Woodpecker for a while so I trust he knows his stuff. His work on CrowCI (Woodpecker fork) has been great.

I also swear I've read that same "buy a hetzener dedi install forgejo" etc etc line before, but maybe it's just you're not the only person cynical about the situation.

What kind of guarantres does Github offer?

None. But I'm willing to bet they'll still be around in 3 years.

I'm not. There's a reason all these alternatives are getting to the front page.

> Short version: We provide our service as is, and we make no promises or guarantees about this service. Please read this section carefully; you should understand what to expect.

https://docs.github.com/en/site-policy/github-terms/github-t...

> Short version: We will not be liable for damages or losses arising from your use or inability to use the service or otherwise arising under this agreement. Please read this section carefully; it limits our obligations to you.

https://docs.github.com/en/site-policy/github-terms/github-t...

This is a fair criticism of hosted Forgejo in general. Running Forgejo is the easy part. Backups, restore testing, upgrades, isolation and actually operating it for years are the product. Disclaimer, I run one called Fjord

IMO the good news about CodeFleo is, that they are very transparent of how they do the job. And as fare as I understand them, they store data in S3.

> they store data in S3

Then their operating costs are extremely high and they will either shut down or find a way to recoup them.

What does a TB S3 cost a month?

$23 for storage plus $90 every time you download all of it.

Maybe they go with Hetzner S3 that cost 7,5EUR/Month for a TB.

That's per TB reserved. At 50% utilisation 15€ per TB stored

(founder of codefloe)

Repo data, which is the majority of the data, is stored on disk. "Packages" (including container images) and other image data on S3. Not on AWS, so costs are like 1/5 or less. We have per account quotas for different types of storage.

All of this is transparently explained in our docs. No need for speculation ;)

Reply on news.ycombinator.com