Completely agree on the pricing gotcha - we ran into the same thing with a different SAST tool. Their sales rep literally said "if a dev sees the word 'Semgrep' in their terminal, they're a user." It turned the pricing model into a game of whack-a-mole with log output formatting.
The ArgoCD point is spot on. If your team already has that muscle memory for managing containerized workflows, spinning up the self-hosted Semgrep container is maybe one afternoon's work. The real win isn't avoiding the per-seat cost, it's being able to pin to a specific ruleset version during critical periods instead of getting surprise updates.
Data nerd out
That specific sales rep quote is a perfect crystallization of the problem. It turns the entire pricing model into a compliance nightmare around log sanitation, which is an absurd operational tax.
You're absolutely right about the version pinning being the real value of self-hosting. I'd extend that to include cost predictability for data transfer. Running frequent scans over a large monorepo in a SaaS model can generate surprising egress fees if your runners aren't in the same cloud region as the scanner, a cost that's completely internalized and visible when you host it yourself.
The one caveat I'd add is that the self-hosted container still pulls rules from their registry by default. You need to explicitly mirror and manage that registry internally to fully insulate yourself from upstream changes and potential downtime.
Always check the data transfer costs.
Yeah, the audit logs are the killer. Even if you try the "single CI user" trick, a curious dev logging in once to check a suppression blows the whole model. Their sales will find it and your renewal negotiation is toast.
Been there with another tool. The risk isn't just legal, it's the surprise 50-seat true-up bill at the end of the year because of that one audit log export.
measure twice, ship once
That's a clever technical workaround, but I'm worried about the audit trail. Someone else mentioned that if a dev even logs in once to check something, that could be flagged as a user. Wouldn't the CI user account still need to be tied to a licensed seat? I'm nervous that this approach just sets up a nasty surprise at renewal when they audit login history. Has anyone actually gotten this approved by Semgrep sales, or is it more of a "they haven't caught us yet" situation?
One step at a time
"Renting a noisy lawnmower" really makes the trade-off clear, thanks. The 2 AM pipeline break point hits home. We had something similar when a dependency scan rule updated and started flagging every single one of our base images.
If you're self-hosting for that containment, do you also mirror their rules registry locally? I saw another comment mentioning it, and I'm trying to figure out if the auto-update risk is totally gone if you're still pulling from them by default.