Hacker News Reader

Comment by embedding-shape | Hacker News Reader

I'm surprised people still rely so much on GitHub. Anything I want to (have to*) be able to deploy on a moments notice, for hotfixes and what not, was moved away from Github like a year ago, because of the horrible uptime. Did others not get the memo yet?

It's not getting better, if anything it's getting worse. Best time to get off GitHub was yesterday, the second-best day to get off is today. Tangled, Codeberg or self-hosted Forgejo (my approach) or Gitea are all good alternative solutions here.

View on HN

It's crazy but there's really still so much out there where hosting on GitHub is practically a requirement, with no other solutions on the market. Off the top of my head, stuff I encountered in the last month:

1. Homebrew really, really wants you to host your taps on GitHub. The docs are very GitHub-focused: https://docs.brew.sh/How-to-Create-and-Maintain-a-Tap as are downstream projects like dist: https://axodotdev.github.io/cargo-dist/book/installers/homeb...

2. Terraform and OpenTofu public registries support only GitHub, see e.g. https://developer.hashicorp.com/terraform/registry/modules/p... and https://opentofu.org/docs/language/modules/develop/publish/#...

3. Only GitHub allows you to use free minutes on managed Windows and macOS runners, which are essential for building and signing native Windows and macOS/iOS software. GitLab's are in beta and require a paid plan, Buildkite requires you to pay at least $30/user without any bundled macOS minutes and no hosted Windows runners available. And for small shops, keeping the macOS and Windows runners clean is such a stupid time sink, with the small number of minutes involved it's much more preferable to just start with free managed minutes and plan to pay for managed runner minutes later.

A recent one for me is Anthropic's first party cloud stuff all assumes you're cloning from GitHub.

In those cases, it's more often than not enough to just have a read-only mirror on GitHub, that gets automatically replicated when your true upstream gets updated. Might mean a bit more machinery, but I'll take that over letting some flaky Microsoft service stop me from delivering what I promise my users.

It's free and you can get it up and running pretty much instantaneously with a coding agent. That's it.

They really should be partitioning their infrastructure so that their paying customers are not in the blast radius of outages from the legions of repos running their 700 test vibecoded regression suite every time they change a config file.

I’m sure they’re working on that, but that takes time. It definitely doesn’t happen in the relative “overnight” that this new influx of code spam spun up.

> Did others not get the memo yet?

Perhaps we're not so dysfunctional that we regularly need to "deploy on a moment's notice." That's a business smell.

>> Anything I want to (have to*) be able to deploy on a moments notice, for hotfixes and what not, was moved away from Github like a year ago, because of the horrible uptime. Did others not get the memo yet?

This misses the point in a bad way. You shouldn't have a single deploy funnel to begin with. You should be able to do deploys from multiple places.

Sure, and backups should be replicated over 3 mediums, and you shouldn't deploy bugs into production, and...

Lots of things we should do, only a few we actually have time to fix. If I were choosing between "Migrating away from GitHub" and "Adding another way to deploy in case GitHub is down", I'd take advantage and do the first, because you'll end up having to replicate SCM, build infrastructure and so on anyway, why not do it properly?

> This misses the point in a bad way.

This misses the business reality in a bad way. A typical outage with something like Github is not a big deal for most businesses. Sure, some nerds get annoyed, but that's about it. The extra effort in maintaining multiple deploy approaches for a non-trivial system simply doesn't make business sense in most cases.

This is true.

It's also something that's easy to do if you start from the beginning treating your CI/CD system as something that just runs scripts out of your repo.

Have you ever worked at a company of any significant size?

Reply on news.ycombinator.com