However, I can share what we did to ease on our GitHub Actions bills if it helps.
Effectively we have our own runners hooked so that a job is scheduled, a runner picks it up and goes with it. We still use GitHub Actions but our monthly bill is now flat because we pay for a server. It is about 6x cheaper if not more.
The solution is not open source but it boils down to a Go service that orchestrates firecracker vms. All the vms are pre-warmed so there is always a fresh supply of workers to pick jobs of various sizes.
It is basic and it works. We have not had any issues since deployed.
The runners can be anything from 1 cpu 2 GB to 64GB 8 cpus. We can add more worker types in a config file.
I am not exaggerating when I say that we used to pay 1000s per month for this. Now our bills are in the range of a few hundred. Other dev boxes are done in the same way.
Caveat here being that GitHub is exploring charging a usage-based fee for self-hosted GitHub Action runners [1]. While they've halted it for now, it's something worth being aware of as you assess your costs. This is probably a drop in the bucket compared to the order of magnitude savings you've described.
[1]: https://github.blog/changelog/2025-12-16-coming-soon-simpler...
"Don't do this. It works, but I don't like it."
It seems like a perfectly cromulent business practice to me, unless they start suing people who didn't give them credit cards.
You use the service. You're told, after awhile, that you've racked up a bill. You keep using the service. You're told your racked up bill is bigger.
And yet, the reason you're using the service after the first bill is because you find it valuable.
You have two choices. Pay up to keep using it, or stop.
The fact that you decided to pay up to keep using it is actually, imo, a pretty good advertisement for the service.
I think the author is being kind, both to themselves and startup practicing dark patterns. He walks through his own thinking, raises important questions and also gives the benefit of the doubt that I wouldn’t give.
IMHO, the article gets ahead of criticism well: accepting the valid critiques while also confining the weird/lazy ones to downvotes.
Well, I should have probably said that instead of sued. But the intent is the same.
> I think the author is being kind, both to themselves and startup practicing dark patterns.
It's unclear it's a dark pattern. The author explicitly states that this particular EULA doesn't allow them to bill without a credit card.
But it's also unclear that this practice will survive the exposure on hacker news.
No, not because it's a "dark pattern" but because it enables customer dark patterns. Run up a bill and then go use something else.
1) They intended a bait-and-switch, where they were going to go after everybody for non-payment. According to the article, they might not even have a leg to stand on here.
2) If you take the quote from the company at face value, they realized that their free quota would be insufficient for conversion for some customers, and decided not to shut off services in the middle of evaluation. In this instance, the bill is a communication in advance -- if you provide a credit card in order to keep using our services, we want to get paid for everything you used after the free limit.
Now, you can argue (and many are) about whether this is a good business practice or not, but it really doesn't matter. After making the front page of hacker news, it's probably not one they're going to continue, simply because now that everybody knows about it, you'll probably have a lot of bad actors doing multiple signups, just to siphon off as much token usage as possible.
That would be much more acceptable. If it worked out and you want to continue, you won't have a problem paying for the overage. If you decide it's not for you, then you can walk away and owe nothing. If it were communicated that way it would be a different situation.
My own answer is that there is nothing (incromulent? uncromulent? well, anyway, not cromulent) about suing people who knowingly and deliberately racked up debts with you, but that common business practices, including the overwhelming abundance of free services everywhere in every product category, and the ability to immediately shut off internet services when you aren't paid, lead to sort of a gestalt of expectations about how things are done.
The article itself says that the terms of service only allow billing if a payment method have been provided, so suing absent that provision would probably be a non-starter anyway.
On the bright? side, suing would definitely keep them on the front page of hacker news longer.
There's no rule that domain names expire unless you renew them, at least for ccTLDs. It's just a convention. Conventions lead to assumptions, and assumptions can be used to scam people.
In general there's two types of businesses: businesses where you pre-pay (e.g. McDonalds), and businesses where you post-pay (e.g. a sit-down restaurant). If you take a conventionally pre-pay service and apply post-pay pricing to it, you have yourself a perfect scam.
[1] https://www.reddit.com/r/sysadmin/comments/1bnjus/the_austri...
https://www.nic.at/en/how-at-works/domain-holder#id105
> I received a letter from the debt collection agency. What can I do?
> If a domain hasn't been paid for despite several payment reminders from nic.at, the domain shall be locked and the open claim handed over to our debt collection agency. As a result, the invoice must be paid directly to the debt collection agency. Please contact our debt collection agency for more information
Like TFA it's hard to tell if they genuinely believe that they are helping their customers by not discontinuing their service, or if it's a scam. I suspect a mixture of both.
Basically, in most countries paying money is something that requires continuous enthusiastic consent - if you don't pay, that's the business's problem and they should stop serving you, and they may only recover payment for goods they've already given you and not received payment for. But in DACH, it only requires technical consent - if you signed something saying you'll give them money, then you have to give them that money, and you cannot rescind your obligation to pay, except as provided in the contract or an overriding law.
You went to Austria and did Austrian business with an Austrian company, you should be aware that Austrian rules and norms apply. ccTLDs are not generic, every country is free to apply any rules on their ccTLD!
Plus they have to pay a fee for chargebacks regardless of whether they think it's valid or not, so strong disincentive.
I know it wasn't me because I gave up entirely on the service after they changed something about their login systems to reject my password and I could no longer get in. Support wanted me to jump through a lot of hoops and I just refused, choosing instead to just stop doing business there because I wasn't really watching anything at that point anyway.
This was around 2022, mind you, so they tried to renew me after several years with no explanation.
Startups are usually resource-rich and time-poor, and don't want to allocate employee time to infrastructure unless it's core to their business, so arguments for efficient spending there are easily overlooked.
Unless you can optimise your CI runtime to be very balanced and fast, you're going to have a lot of jobs queued during working hours ... although it costs more per minute, the fact that CI jobs are bursty means it works out not too much costlier but with less queue time.
Sounds like you need to share infra with an org of similar needs in a vastly different timezone.
I guess that's what SaaS CI solutions are in a way. :)
It's Talos Linux on Hetzner VMs where all resources are managed via kubenix, and all CI runners are running NixOS.
So... extremely affordable and extremely performant, but very complicated.
Drop me an email if you want the writeup when I get around to making it.
Until then, here's a Forgejo Actions that compiles its own CI runner image:
https://git.shine.town/infra/runners/src/branch/main/.forgej...
No Docker involved in the build process, it's all Nix.
Unfortunately the CI runner itself is still Docker-in-Docker because:
https://codeberg.org/forgejo/discussions/issues/66#issuecomm...
...boilerplate...
...more boilerplate...
Terms... and conditions...
...limitations...
...liabilities...
Go get a $20 gas station credit card. They get THAT card, and whatever name you want to provide.
When they demand $x000 for their free trial, they get.... $20!
And before anyone bemoans their 50+ page onesided "contract" that weasel-words revokes 'free trial'... Sure, they can publish a claim and sell off a debt to "John Q Public". We can see how far they'll get with that.
And let me know how a lawsuit against "John Q Public" will go, along with an email from fakemail.net and a gas station preloaded credit card.
Companies deserve this sort of treatment if they say shit like "FREE TRIAL" and silently convert you to 'you owe money' with no hard limits. And naturally, paragraph 37, sentence 12 includes this disclaimer. That should be blatantly clear, but its not cause they are scammers.
So, fuck'em.
The argument of "like many early startup do, we oversaw this and ignored that" doesn't really make it better.
In German-speaking (DACH) countries the companies aren't lazy and they will take you to court and the court will make you pay all legal and court fees as well as the debt. It's a near certainty they will bother. In the USA you're hoping they won't bother and they'll be satisfied with just banning you as a customer. I think this is because each party pays their own legal fees in the USA.
Lessons learned:
1) When you spam your users with too many emails (engagement! marketing-thinly-wrapped-as-transactional-information!), they stop reading your emails
2) Read your damn emails
Blacksmith can send as many invoices as they want.
If the other business doesn't think it's worth the cost after the free trial, they don't have to pay the invoices.
Well, there are other drop-in GHA runner services, so I wouldn’t see why anyone would be tied into a specific provider.
Namespace.so are one and my experience with their support has been incredibly positive. Great team there.
Honourable mention to WarpBuild as well, who I used before them.
Can't believe they continued using the service after this. I would refuse to pay (they have no legal basis to require payment, and their own terms of service seems to disagree with their behavior) and find a more ethical provider.
It's not illegal or even unethical to bill someone who hasn't given their CC, but it's definitely unexpected.
In Europe it's perfectly normal to be bound by terms of a paid service. I would never expect to avoid being liable for payments for services rendered only because I didn’t enter a cc number before exceeding free-tier limits.
Even in the comments below people are stating that this bill is valid only if they want to continue using the service.
I mean, it's a sleazy practice, especially considering how they word their emails, but I wouldn't expect something for nothing just because I hadn't set up a billing mechanism yet.
The least-resistance path out of such a bad equilibrium is regulation. And they did add a lot of protections in the last decades, which probably helped too. Some would say places like the EU even added too many. But I'm pretty sure that "if you're using our product, you need to pay" would fly even in the most customer-friendly jurisdictions today.
> While amusingly as of June 8 Blacksmith’s terms implied that their right to bill you is contingent on you providing payment information, a SaaS app certainly could have terms that obligate users to pay for unexpected overage when on a free trial.
> And let’s be clear: our agents run a lot of CI jobs, so we did expect to hit the limits of the free plan. We used the service and got value for it. So it’s not inherently dishonest, just surprising. My read is that they can do this.
So I read this that the terms say "blacksmith will only bill you if you provide payment information" but then they say that blacksmith can bill you if you don't provide payment information. That seems to contradict the terms, which I would assume underlie the "contract" that you agree to when agreeing to the terms.
