Agreed - we've made this copy change to the free usage email now, and the change to add a toggle for preventing runs when you run out of credits is going through CI.
Yeah, I hear you on the inversion of expectations and I think you're exactly right about how this affects perceptions of the product.
Candidly, right now, we're more likely to land on an opt-out rather than opt-in here since getting your builds to actually run again requires a code change. I think there's a full blog post to write about why we think this is the right default, but we're still thinking it through.
Regardless, we need to make the choice loud and visible, and our miss was making it too hidden. We'll close that gap.
I partially disagree! We issue an invoice because the customer did consume the services - a lot of folks appreciate that, since it gives their AP team a real cost to work from instead of a ballpark of us vs. GitHub.
My "we never pursue these" comment wasn't about us knowing the charge was shady - it was to clarify we have no strategy of chasing people/litigating over invoices they weren't aware of, which came up a bunch in the thread.
I do agree that pushing surprised customers through a support ticket is wrong, and that our in-product language compounded that issue. Controlling this belongs in the product so we can hit the mark on trust - we're building that now.
This isn't shady for most folks, since they're typically comparing us to known, expensive alternative. For those who are surprised by their spend (which given GHA's upper-bound pricing has been a minority) our reconciliation flow was for them to contact support, and my comment was to clarify that we don't have an intentional strategy to pursue folks for invoices they weren't aware of. It's clear to me that controlling this behavior belongs in the product so we can hit the mark on trust - we're working on adding that now.
First off, fair point on the free tier email. This fits in the same theme of clarity vs. trust for me: if we say disruption, but then leave your account enabled, that still feels deceptive even if it seems generous to us. We will fix.
On your last point - I just want to note that this isn't a money-maker for us. Runner bills can be large (as they were here!), and we explicitly wanted to avoid actual charges to the user in favor of not collecting for a good amount of usage. Again, there's a clarity/trust tension there that you're right to call out, but the end goal is that more people can use cheaper, faster runners.
We earn that trust today by being extremely easy to use and delivering on what we promise, and we need to add clarity to that list. Thanks for the feedback.
Hey folks - Greg here, I do product at Blacksmith.
I want to say upfront - we've never pursued these invoices. If someone feels they didn't get value from the service, we've eaten that cost and always will.
There's a bit of an implicit policy decision on our side here that we did a bad job of communicating - I want to clarify that, and then talk about how we can fix it.
First, we wanted to let customers start using Blacksmith without a credit card. Very few infra startups do this today - CC validation is great for anti-abuse - but doing so has let us support a much greater number of free users.
Many of these free users have turned into full OSS sponsorships (most recently ccusage, and before that, OpenClaw) or large paying accounts, and we haven't wanted to cut those users off from trying us. It's a real pain point to find a credit card to put down for your company or OSS project's CI spend before you've even tried the service.
Second, not having a credit card on file means we don't actually know when credit card-less users intend to continue past their free trial.
Shutting down users CI workloads entirely seemed harsh, especially because doing so would fail builds and require a code change to resolve. If users could start without a credit card, we weren't going to then hold their runners hostage. Instead, we decided to just eat the cost for the small number of users who either abused our services or did not actually mean to use the service.
This worked, mostly - though every month we have gotten a number of support cases with users confused about their invoice. If they didn't intend to use the service past the free tier, we've voided out the invoice, and often given credits against a future bill if they intended to use the service, but were surprised by the behavior.
We have a lot to improve about our billing mechanics - but because our retention rate for these users has been so high, we have assumed great support could catch and resolve the ambiguity.
That said, there's two changes we can make now:
1. we clearly missed the mark on supporting this specific case - we should have offered to void this bill entirely given the surprise factor here.
2. We're prioritizing up making progress on a Wallet implementation that will let folks choose to suspend their runners rather than let them continue to run after they use up their free tier.
We also just launched a new billing/metrics view so users have better visibility into their free tier and Blacksmith usage.
I'm sorry for the bad taste this has left in everyone's mouth - I'll be hanging out here and on greg [at] blacksmith [dot] sh if you want to talk about your account specifically.
We work with supabase - so your DB still deploys out to them, but we cache queries in memory so they're significantly lower latency. Since we're offloading reads, we also help handling traffic spikes, lower costs, etc.
ReadySet is a new database cache engine that speaks SQL and automatically handles cache eviction by listening to your database's replication stream. Your application issues the same queries as before, they're just blazing fast and cost less.
We have openings across the stack:
- Rust engineers for our core dataflow engine.
- Front-end engineers and a Product Designer for our query analytics and cloud UI.
- Cloud engineers to build out our cloud-hosting service.
Hey, PM @ ReadySet - fair points, and thanks for checking us out.
We've been in pretty heavy development and have been heads down on getting ReadySet into your hands as quickly as we could. We'll be doing a major documentation pass soon which will have more info about clustering, etc.
Just clarifying - D1 without read replicas is strongly consistent. If you add read replicas, those can have replication lag and will not be strongly consistent.
1) A Durable Object is a global singleton instance of a Cloudflare Worker that is addressed by an ID. You define that Worker’s behavior via a JavaScript class. That Worker can then write to a persistent storage API, which is backed by a strongly-consistent KV database.
2) yes, the storage API is strongly consistent.
As an example, say you had a Durable Object for each user’s configuration. You’d have a class called Config, and you’d access the Durable Objects associated with that class by calling their id from a Worker.
When a network request is received that routes your Worker, we’d run your Worker code in whatever datacenter we receive the request in.
If that Worker needs to access the user’s config data it would make a request for the Config Durable Object with that user’s id. That request is forwarded to a singleton Worker (which we call a Durable Object) running somewhere on our network. All of the requests for that User’s config data originating all across Cloudflare’s network will execute serially on that Durable Object, and can modify storage associated with the Object.
This means the Durable Object can both store state associated with the User’s config, but also expose methods and functions related to the user (for example, a function resetLogin() that resets their password).
3) while the DO has access to a KV storage API, they more closely resemble the Actor pattern or Azure’s Durable Entities.
4) they’re similar. Lambda@edge runs a container at a small number of AWS edge locations, while a Worker runs JavaScript or WASM code at a Cloudflare’s edge in response to a network request. Workers are much lighter weight, less expensive and have better performance characteristics, while supporting a smaller list of programming languages.