This is an interesting approach especially if you factor in that re-minting a key is usually a lightweight task compared to what most API calls have to interact with.
If the re-minting happens transparently with a user interaction then you spread out some of the request velocity that can come with that (if you're operating at a large enough scale for it to matter for this to be a concern).
Calendar Versioning (CalVer, YYYY.Release.Patch) fulfills the same need and you can see it in practice with Jetbrains (e.g. the latest version of IDEA is 2025.3.6).
The only difference is Jetbrains uses YYYY.R for marketing, see: "What's new In 2025.3"[1]
>But before I did so I researched first. I asked a few instances to analyse the project in terms of gains of complexity, stability, testability, etc., and while (obviously) stability would drop (no types in Ruby) it’s not that awful (Sorbet has types in Ruby!).
Is it not a rage-bait argument to say that not having types implies less stability?
Ah, I was using GH's webui instead of downloading to view the PDF and it stopped loading at slide#47...rereading it now paints a much better picture. Thanks!
If I followed, Rust's memory safety guarantee means sacrificing roughly ~3% performance with some worst case paths being ~15% (compared to C++ performance)?
Is it too much to ask for a not-vibe-coded billing system? In my opinion, we need better systems to hold these companies accountable as I don't believe the $20/dispute they're paying means much given how common other customers are complaining about billing irregularities just in this thread alone.
OP's ask was: "Is this another one ... where open source is used more as a marketing gimmick"
My original comment wasn't intended to indicate that there is an obligation to provide support. The deliberate choice to: a) not offer paid support for open-source deployments, and b) sunsetting the Kubernetes deployments in favor of their cloud version, is a signal that shows PostHog doesn't /really/ want you to be running the software in a self-hosted manner.
Just look at the "Open-source hobby deploy" (from the README in git) which calls out that it "should scale to approximately 100k events per month" but their cloud offering gives you 1 million events per month for free. What is the point of the hobby "deploy"?
Back to OP -- my answer is yes, this is a source-available service that you can modify and play around with locally. The source and documentation behind the operations of PostHog aren't available.
Fairly accurate, you can only get support if you're using their cloud product.
"We no longer support paid, open-source deployments and it is no longer possible to buy licenses for self-hosted versions - we instead recommend migrating to PostHog Cloud." - from: https://posthog.com/docs/self-host
Could you share why?