> November 4, 2026: We’ll have a brownout of the removal of the ssh-rsa signature type (i.e., RSA keys using SHA-1) and the diffie-hellman-group-exchange-sha256 key exchange algorithm.
I guess something went sideways.
a-squirrel-comm 2 hours ago
> November 4, 2026: We’ll have a brownout of the removal of the ssh-rsa signature type (i.e., RSA keys using SHA-1) and the diffie-hellman-group-exchange-sha256 key exchange algorithm.
I guess something went sideways.
igleria 2 hours ago
a-squirrel-comm 2 hours ago
igleria 2 hours ago
qtqtqt 2 hours ago
dist-epoch an hour ago
SkiFire13 30 minutes ago
mschuster91 14 minutes ago
eknkc 3 hours ago
misswaterfairy 3 hours ago
Gitea Enterprise would be worth looking at.
eknkc 2 hours ago
import 2 hours ago
michaelbuckbee 2 hours ago
I have it for all my stuff (dozens of repos and hundreds of PRs/builds per week) and it's only once in the last year that I've exceeded the free resource levels. I don't know if it's just extra capacity or they're burning VC dollars in the hopes of inspiring posts like this, but either way I feel like I'm taking advantage of them at this point.
crote 2 hours ago
tcfhgj 8 minutes ago
pelagicAustral 3 hours ago
saturn_vk 2 hours ago
import 2 hours ago
raddan 2 hours ago
rozularen 2 hours ago
myaccountonhn 2 hours ago
jelder an hour ago
embedding-shape 34 minutes ago
Begin by refactoring the deployments so they're driven by checked in shellscripts, that accepts a git reference to deploy (prefer immutable commit SHAs over mutable branches/tags). Make it use the stuff it already has checked in, and make the actual GitHub Actions stuff as small and concise as possible, ideally each "run" should just call a shellscript with the git reference.
Then move so the deploys happen not on GitHub Actions itself, but on a "intermediate deploy host" that has the source code and access to the credentials you need, and make this host have one secure entrypoint, where someone (or something) can enter and run shellscripts, after pushing their code as a normal git push. Then switch so the deploys from GitHub Actions instead use this new host to do the deploys. Lock down this host hard.
When GitHub and/or GitHub Actions go down, the developer responsible for deploying stuff, should be able to get temporary git and ssh access to this host, can push any git data straight to the host, and their user on this host can run the deploy scripts. Keep in mind that nothing in your deployment process should depend on stuff that isn't also available on this "deploy host", if you have multiple synced repositories and so on.
Now things mostly work the same as people are used to, with the added benefit that when things go down again (like next week), you'll still be able to continue to deploy stuff.
I've done this refactor/migration for tens of companies in the last year, more or less following this exact template for all of them, with no issues reported from either of them, but lots of praise :)
SkiFire13 28 minutes ago
bonetruck 15 minutes ago
stack_framer 5 minutes ago
rarisma 2 hours ago
- - > i wake up - -
| |
| V
github has an outagethesdev 3 hours ago
nope1000 an hour ago
cashbreaker 2 hours ago
techterrier 2 hours ago
git -c credential.helper= -c 'credential.helper=!gh auth git-credential' pull https://github.com/myorg/my-repo.git
sognetic 3 hours ago
ayhanfuat 3 hours ago
> [email protected]: Permission denied (publickey). fatal: Could not read from remote repository.
Please make sure you have the correct access rights and the repository exists.
chinathrow 2 hours ago
b1tshift 2 hours ago
igleria 3 hours ago
solyin 3 hours ago
selectnull 2 hours ago
marvstazar 2 hours ago
https://rubyonrails.org/2026/11/4/Rails-8.0.5.2-and-8.1.4.1-...
fauzanhilmi 3 hours ago
swe_dima 2 hours ago
git config --global url."https://github.com/".insteadOf [email protected]:
so it pushes / pulls using HTTPS
when things are back to normal run:
git config --global --unset url."https://github.com/".insteadOf
misnome 2 hours ago
I can live with the occasional outage but this is a constant problem.
w3ll_w3ll_w3ll 2 hours ago
feukon 2 hours ago
crote 2 hours ago
Developers are expensive. If I can't ship a feature on time because GitHub issues keeps forcing me to switch to different tasks to work around git/PR/ticket/Actions downtime, then that costs my company real money - despite us not being the source of the AI DDoS that GitHub has happily been welcoming.
To me, the situation is very simple: either 1) rein in the AI deluge, or 2) isolate paying customers from it, or we'll move to an alternative.
For businesses the current state of unreliability would be unacceptable if it was completely free, the fact that it is actually paid just adds insult to injury.
fredsted 2 hours ago
grishka 2 hours ago
Maybe they need a better AI model for their vibe coding. That'll fix everything, right? At least that's what my friends keep telling me when I say that the free LLMs I played around with a bit are incredibly dumb.
chinathrow 3 hours ago
dude250711 2 hours ago
esher 3 hours ago
anon7000 3 hours ago
crote 2 hours ago
rvz 2 hours ago
It's up to you if you want more of this instability. Perhaps you should consider a self-hosted alternative.
larsnystrom 2 hours ago
refactor_master 2 hours ago
malikolivier 2 hours ago
Some of our customers unexpectedly started using the service we're running as a file-cache around GitHub to mitigate GitHub outages.
We wrote about this use case in our blog: https://www.stablebuild.com/blog/protect-your-builds-from-gi...