Hey everyone. Looking at FOSSA for our startup's compliance needs. The cloud version seems straightforward, but our investors are pushing for on-prem due to some client contracts.
For those running the on-prem version: how much of a time sink is it to maintain? I'm the de facto IT guy here and already juggling a million things. 😅
Specifically:
- How often do updates come out, and how painful is the upgrade process?
- Are the hardware/resource requirements pretty accurate, or did you need to scale up quickly?
- Any hidden costs beyond the license? (Besides my sanity.)
Yeah, that "de facto IT guy" feeling is real. We're in a similar boat with client contracts dictating on-prem.
> How painful is the upgrade process?
It's not terrible, but you have to schedule the downtime. The updates come every few months and the process itself is scripted, but you'll still spend a couple hours babysitting it and checking integrations afterward. The docs are okay, but I've had to reach out to support once or twice when something didn't come up cleanly.
On resources, we found the specs in the docs were a bit optimistic once our repo count grew. The big hidden cost for us was storage for the artifact cache - it ballooned faster than expected. Make sure you've got monitoring on disk space from day one, or it'll fail quietly in the middle of a scan.
learning daily
Oh I feel that. I was worried about the maintenance time too.
The upgrade downtime is manageable like user398 said, but for us the bigger time sink was actually the initial setup and config drift. I had to write a bunch of extra ansible playbooks to keep our non-production instance in sync, which wasn't mentioned upfront.
Also, budget for more CPU than the docs say if you scan large monorepos. We hit timeout issues until we doubled the allocated vCPUs.
That's a critical point about config drift. We saw something similar, but our issue manifested as increased scan latency during peak dev hours because the underlying orchestration wasn't keeping pace with the container scheduling. It wasn't a timeout, but a gradual performance degradation that looked like a resource issue until we traced it back to config state.
Doubling vCPUs was necessary for us as well, but it exposed another layer: the network latency between the scanning nodes and the artifact cache became the new bottleneck. Once you scale compute, you often have to reassess your internal network topology and storage I/O.
Every microsecond counts.
Totally agree that scaling compute just shifts the bottleneck. We hit the exact same wall with network latency to the artifact cache.
I'd add that the type of storage backend for that cache made a huge difference for us. Using the default local SSD on the node was fast until we scaled nodes, then consistency was a mess. Moving to a high-performance network-attached block store solved the latency but introduced a whole new cost dimension nobody mentioned during the sales cycle.
keep it evidence based
> Has anyone tried the on-prem version? How's the maintenance overhead?
The overhead is nontrivial and extends beyond just applying updates. The real cost is in managing the entire supporting infrastructure that the on-prem version suddenly makes your problem.
The specs are a starting point, but your scaling factor depends entirely on your repo topology. If you have a dozen small repos, you're fine. If you have a couple massive, monolithic codebases with deep dependency trees, you'll be scaling compute and storage like the others said. The hidden cost is the operational toil of tuning that infrastructure - adjusting timeouts, scaling cache storage I/O, and managing node configurations.
What's your current average repository size and count? That'll tell you if you're in for a rough ride or a manageable one.
fix your schema