Team of 20, cloud-native shop on AWS (EKS, Terraform). We used Claw's cloud service for secret scanning in our pipelines for about a year. Compliance requirements are pushing us to keep all data on-prem, so we had to switch to their self-hosted enterprise offering.
The documentation promised a Helm chart for a simple deployment. Reality was a 15-step checklist of pre-requisites that weren't in the main guide. The container images were in a private registry that required a manual token rotation process just to pull. The "quick start" values.yaml was anything but.
```yaml
# Example of the misleading config. This 'ingress' block created nothing.
ingress:
enabled: true
className: "nginx"
# Missing mandatory annotations for our ALB controller.
annotations: {}
```
The main pain points:
* The internal PostgreSQL dependency had a StatefulSet with persistent volume claims that would fail silently on our storage class.
* The scanner workers required a specific node label, but the chart's affinity rules were overly permissive, causing pods to schedule on inappropriate nodes.
* Initial synchronization of vulnerability databases required opening support tickets to get a one-time data dump.
After three days of troubleshooting, we got it running. The core lesson is that "self-hosted" for many vendors means they've packaged their cloud product and washed their hands of the operational complexity.
If you're considering this path:
* Triple the estimated setup time.
* Demand a full, non-public prerequisites document.
* Validate every external dependency (registry access, database, object storage).
Secure by design.
SecDevOps
We're a 12-person fintech SRE team, also on AWS/EKS. I run a self-hosted secret scanning setup in prod, integrated into our ArgoCD pipelines.
* **Deployment Friction:** Claw's "simple" deployment is a known time sink. I had similar issues: their Helm chart's default resource requests are unrealistic for initial sync (needs 4Gi+ memory per scanner pod, not the documented 1Gi). The pre-sync of vulnerability data took 45 minutes on a direct vendor S3 link, not the "seconds" suggested.
* **Hidden Operational Cost:** The real cost isn't the license. It's the ongoing database maintenance for their internal Postgres. At my last shop, we spent 3-4 hours monthly on pruning and vacuuming that StatefulSet. Their cloud service abstracts this; the self-hosted version makes it your problem.
* **SLO Impact:** Their scanner's API response time degrades under load. For a batch of 50+ repos, the 99th percentile latency jumped to 8-12 seconds in our environment, which risked pipeline timeouts. You need to tune worker count and queue limits aggressively.
* **Support Reliance:** For self-hosted, you're locked into their support for initial data sync and schema updates. Average ticket resolution for a broken version upgrade took 36 hours for us, which is an unacceptable deployment blocker.
I'd only recommend their self-hosted version if you have a dedicated platform engineer to babysit it and no other compliance-approved SaaS alternative. If you don't, tell us your team's capacity for managing a stateful scanning service and your pipeline's max acceptable latency increase.
SRE: Sleep Randomly Eventually
Yeah, the SLO impact point is real. We saw the same latency spike in batch mode. It turned out their scanner's default concurrent connections to the internal registry were throttling themselves, creating a queue.
We ended up overriding the worker config and scaling the pods horizontally, but then we hit their Postgres connection limits. The hidden cost is tuning the whole stack to get back to cloud-equivalent performance.
>locked into their support for initial data sync
This was the worst. Our initial data sync failed silently, and support asked for a tarball of the entire database to debug. Took a week to get a clean seed.
Oh man, the private registry token rotation was the worst. We got bit by that too. Had to write a pre-pull step in our Terraform just to get the images onto the nodes before the Helm install could even start.
> scanner workers required a specific node label
This! The default affinity tolerates all nodes. We had to patch it like this to pin to our scanning pool:
```yaml
worker:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: node.kubernetes.io/instance-type
operator: In
values:
- m5.xlarge
```
Did you find their Postgres storage class issue caused problems during upgrades? I'm scared to try a minor version bump now.