Yes, excluding the virtualenv folder does blind you to library security issues. The free tier creates a difficult trade-off between scanning your own code and your dependencies.
I track this for my projects in a small spreadsheet. A Flask app with only Flask and SQLAlchemy in its virtualenv might add around 15k lines to the scan. That's a significant chunk of the 100k LOC allowance, but it may be worth it for the dependency check. Adding a larger framework or utility library can easily double that.
The pragmatic choice for a side project is often to exclude dependencies and handle their security updates separately via tools like `pip-audit` or GitHub's Dependabot in your CI, before the code even reaches SonarQube.
Measure twice, buy once.
Totally agree on tackling critical vulnerabilities first. It's the only way to stay sane with a legacy codebase.
I've found the "fix as you go" approach works best when you sort by severity and then by file modification date in the SonarQube UI. That way, you're always hitting the fresh, high-priority stuff in the files you're actually working on.
Data is the new oil - but it's usually crude.
Yes, it will count everything in your scannable directories, including `node_modules`. That's an easy way to blow through your limit before you even see your own code.
You need to set up exclusions in your analysis configuration. Look for the `sonar.exclusions` property. For a JS project, you'd add `**/node_modules/**` to that list. Just be aware you lose the ability to see security issues in those dependencies.
If dependency scanning is important to you, you'll hit that ceiling fast. The free tier is really for your proprietary code only.
—hd
Yeah, that initial issue flood is rough. The free tier is okay for a single project if you exclude dependencies like others said. I'm also trying to figure out the workflow part.
>Do you fix as you go, or do a cleanup day?
I'm leaning towards a mix. I'll fix a critical bug if I see it while I'm in the file, but I save the big "code smell" refactors for a dedicated session every couple weeks. Otherwise I get stuck in endless cleanup and my feature never gets done.
How do you decide what's a "must-fix now" versus a "can wait"?
Trying to figure it out.
That mix sounds like a good plan. I'm new to this, so I worry about getting overwhelmed too.
>How do you decide what's a "must-fix now" versus a "can wait"?
I look at what the quality gate says will actually block my merge. I figure if it's stopping the pipeline, it's a must-fix. The rest I tag with a comment and come back later. Does that logic make sense, or am I missing something?
I know that feeling. The background noise thing is real, especially if you're mostly interacting with SonarQube through the pipeline gate. The old issues in untouched files can just fade into the wallpaper.
One way we've tried to keep it from getting stale is to use the "code age" filter when doing our monthly review. We'll pull up issues older than, say, 6 months and do a quick "should this still be here?" check. It doesn't fix everything, but it prevents total invisibility. Have you tried any periodic review like that?
Stay constructive
The initial flood is normal. The free tier is fine for side projects if you exclude dependencies. Add `**/node_modules/**` or `**/venv/**` to `sonar.exclusions`.
For workflow, I only fix critical bugs and security hotspots in active files. Everything else goes on a backlog for a quarterly review. The quality gate dictates what's urgent.
Ship it, but test it first
Quarterly reviews for a backlog of code smells? That's a fantastic way to ensure they never get touched. The "out of sight, out of mind" principle in action.
You're right that the quality gate dictates pipeline urgency, but letting everything else accumulate for months just builds technical debt you'll have to pay interest on later. It becomes an archaeological dig, and no one wants to spend their sprint sifting through ancient "minor" issues trying to remember the context.
Better to bake a small, fixed amount of cleanup into every story. If you're already in a file for a feature, fix one or two of the older issues there as part of the work. It keeps the debt from compounding and makes the review actually manageable.
monoliths are not evil
That point about the free tier LOC limit is a good one. I was wondering if anyone had a rough sense of how quickly you'd hit it with a typical backend service. You mentioned dependencies, but what about testing files? Does SonarQube count the lines in your `tests/` directory toward that total as well?
Yes, test files do count toward your total lines of code for the tier limit. This is because the analysis engine processes all scannable files by default. The same exclusion property applies, however. You can add a pattern like `**/*test*/**` or `**/tests/**` to your `sonar.exclusions` to remove them from the count if you wish.
For a typical backend service, it's difficult to give a universal number, as it depends heavily on your language and framework. A monolithic Spring Boot application with integrated tests could easily reach tens of thousands of lines. The free tier's 100k LOC can be consumed surprisingly fast once you include all generated code, dependencies, and test suites.
Let's keep it constructive
That's a super important clarification about test files. It's easy to forget they're in the mix when you're just thinking about your main source code.
I'd add one caution about excluding them though. While it saves LOC, you lose the ability to see test code coverage metrics, which is a big part of SonarQube's value for me. So it's a trade-off between staying within the free tier and getting those insights.
Has anyone found a good balance, like excluding old test directories but keeping the current ones?
Beta tester at heart
Your experience with the sign-up and initial issue flood is typical. The key is not letting the volume paralyze your development velocity.
For the workflow question, the "fix as you go" versus "cleanup day" debate often misses a tactical middle ground. I structure it by issue severity and file churn. If I'm modifying a file for a feature, I'll address any Critical/Blocker issues and Security Hotspots in that file as part of the merge request. Code smells in that same file get tagged with a `// TODO Sonar` comment and a ticket is created, but they don't block the merge. This prevents context switching while ensuring high-risk items are resolved in context. I then allocate two hours every Friday afternoon to work through that week's accumulated "TODO" tickets. This balances continuous cleanup with predictable, bounded effort.
Regarding the free tier LOC, for a true side project, it's usually sufficient if you aggressively use `sonar.exclusions`. You must exclude dependency directories (`node_modules`, `.venv`, `target/`). The trade-off, as others noted, comes with test files. Excluding them saves LOC but forfeits coverage metrics. A pragmatic compromise is to only exclude integration or snapshot test directories that see few changes, while keeping your core unit test path included.
Right, that confusion is why most teams end up ignoring code smells entirely after a while, which kind of defeats the point. The categorization can be overly academic.
On your question about automation: no, the free tier analysis doesn't happen magically. You have to trigger it, usually via a pipeline step or a local scan. The easiest way to "forget" is to not bake it into your CI. If you're using GitHub Actions or similar, set it to run on pull requests. Otherwise, yes, you'll absolutely forget, because who wants to manually run a scanner?
keep it simple
>the easiest way to "forget" is to not bake it into your CI.
Exactly. And forgetting is the cheapest option. If you bake it into your CI and it's scanning every PR, you better keep an eye on your cloud bill. I've seen teams accidentally leave old scanners running in parallel or misconfigure them to scan the entire repo history, not just the diff. That can double your pipeline compute costs in a month.
If you're on the free tier, fine, but the second you're paying for compute minutes, a sloppy scanner setup is a direct line-item expense.
cost optimization, not cost cutting
"Super smooth" sign-ups are marketing's job, not a metric for a tool's value.
That 50+ issue flood is the tool doing its job, which is to generate noise. Most of those "code smells" are just opinions baked into a ruleset. Focus on the actual blockers - security hotspots and bugs that crash. The rest is just clutter that distracts from writing code that works.
Free tier LOC? It's a trap to get you hooked. Once your project grows and you need to scan dependencies or tests for coverage, you'll hit it. Then you're on the pricing page.
Keep it simple