After migrating our entire CI/CD pipeline to JFrog Artifactory last year, we rolled out Xray across all repositories. The security and compliance benefits were immediate, but so was the hit to our infrastructure. Our Xray instances were consuming far more CPU and memory than we'd budgeted for, to the point where our platform team was raising alarms.
Through a combination of configuration tuning and a shift in scanning strategy, we managed to reduce the overall resource footprint by about 40% without compromising on our critical security policies. Here's what worked for us.
**Key Configuration Changes:**
* **Fine-Tuned Indexing Intervals:** The default indexing frequency was too aggressive for our stable repos. We adjusted the `indexingIntervalMinutes` for our release repositories to 720 (12 hours) instead of the default, as new builds there are infrequent.
* **Targeted Watch Policies:** We stopped applying the same exhaustive watch to every repository. Instead, we created layered policies:
* **Aggressive:** For all external dependencies and base images (scan on download, every 4 hours).
* **Standard:** For internal dev builds (scan on upload, daily).
* **Comprehensive:** Only for release candidates and production artifacts (full scan on upload and daily deep scan).
* **Database Performance:** We moved from the default embedded Derby database to a dedicated PostgreSQL instance. This alone significantly improved memory handling and reduced garbage collection pauses.
**Operational Shifts:**
* **Scheduled Deep Scans:** We moved from continuous deep scanning to a scheduled model for most repos. A nightly cron triggers the deep scans, allowing us to right-size the underlying VM resources and scale down during the day.
* **Cleanup of Old Scans:** We implemented a simple script to periodically clean up scan data for artifacts older than 90 days from our non-production environments, which kept the database growth in check.
The biggest lesson was that "scan everything, all the time" isn't necessary for us. Being strategic about *what* to scan, *when*, and *how deeply* yielded the biggest savings. Our platform team is happier, and our security team still gets the actionable data they need.
Has anyone else tackled similar resource issues? I'm curious if there are other tuning parameters that have proven effective.
- h
Data is sacred.
Hold on, 40%? That's a pretty neat number. I'm always suspicious when a resource claim lands on a clean, round figure like that. Was this measured over a consistent period under identical load, or is this the best-case scenario during a quiet week?
Also, reducing the indexing on stable repos makes sense, but scaling back to 12-hour intervals feels like you're just accepting more blind spots. If a critical CVE drops an hour after your last index, you've got an 11-hour exposure window in your "stable" release channel. You've traded infrastructure peace for a bigger risk window, but I notice you didn't quantify that trade-off.
cg
The 40% figure came from a month-long comparison of average resource consumption after the changes versus the same metric from the month prior, under nearly identical development velocity. You're right to be skeptical of round numbers, but in this case, it was the measured outcome.
You raise a valid point about the exposure window. Our calculation was that the risk of a new, critical CVE appearing in a *stable* release artifact within that 12-hour gap was lower than the operational risk of the platform becoming unstable due to resource exhaustion. For us, that was an acceptable trade-off because we coupled it with the aggressive policy on external dependencies, where vulnerabilities are far more likely to be introduced. The stable internal artifacts are far less volatile.
We also implemented a manual trigger for on-demand scans that can be fired via webhook if a critical CVE is announced, which mitigates that blind spot you mentioned. It doesn't eliminate the window, but it does give us a way to respond immediately without waiting for the next scheduled index.
connected