Sizing Guide

Sourcebot runs as a single container (vertical scaling). This guide helps you choose the right CPU, memory, and disk allocation based on the number of repositories you plan to index.

These recommendations are based on real-world deployments. Your results may vary depending on repository sizes, search patterns, and whether you use features like multi-branch indexing or Ask Sourcebot.

Recommendations

	Small	Medium	Large	Extra Large
Repos	Up to 100	100 – 500	500 – 2,000	2,000+
CPU	2 cores	4 cores	8 cores	16+ cores
Memory	4 GB	8 GB	32 GB	64+ GB
Disk	50 GB	100 GB	250 GB	500+ GB

We recommend using external managed Postgres and Redis instances rather than the ones embedded in the Sourcebot container, as this adds stability to your deployment. You can configure these with the DATABASE_URL and REDIS_URL environment variables.

Of all resources, memory has the most direct impact on search performance. Sourcebot uses Zoekt for search indexing, and the OS page cache keeps frequently accessed index data in memory. More memory means more of the index stays cached, which translates directly to faster searches and less disk I/O.

Disk usage

Disk is consumed by two things:

1. Cloned repositories stored in the .sourcebot/ cache directory
2. Zoekt search indexes built from those repositories

As a rule of thumb, plan for 2 – 3x the total size of the source code you intend to index. For example, if your repositories total 50 GB, allocate at least 100 – 150 GB of disk.

Multi-branch indexing significantly increases disk usage since each indexed branch produces its own search index. In testing, enabling branch indexing across all branches can triple storage requirements. Start with a subset of branches (e.g., release branches) and monitor disk usage before expanding.

Tuning concurrency

If your instance is resource-constrained, you can reduce the concurrency of background jobs to lower CPU and memory pressure during indexing. These are configured in your config file:

Setting	Default	Description
maxRepoIndexingJobConcurrency	8	Number of repos indexed in parallel
maxConnectionSyncJobConcurrency	8	Number of connections synced in parallel

Lowering these values reduces peak resource usage at the cost of slower initial indexing.

Audit log storage

Audit logging is an enterprise feature and is only available with an enterprise license. If you are not on an enterprise plan, audit logs are not stored and this section does not apply.

Audit logs are stored in the Postgres database connected to your Sourcebot deployment. Each audit record captures the action performed, the actor, the target, a timestamp, and optional metadata (e.g., request source). There are three database indexes on the audit table to support analytics and lookup queries.

Estimated storage per audit event: ~350 bytes (including row data and indexes).

The table below assumes 50 events per user per day. The actual number depends on usage patterns — each user action (code search, file view, navigation, Ask chat, etc.) creates one audit event. Users who interact via MCP or the API tend to generate significantly more events than web-only users, so your real usage may vary.

Team size	Avg events / user / day	Daily events	Monthly storage	6-month storage
10 users	50	500	~5 MB	~30 MB
50 users	50	2,500	~25 MB	~150 MB
100 users	50	5,000	~50 MB	~300 MB
500 users	50	25,000	~250 MB	~1.5 GB
1,000 users	50	50,000	~500 MB	~3 GB

Retention policy

By default, audit logs older than 180 days are automatically pruned daily by a background job. You can adjust this with the SOURCEBOT_EE_AUDIT_RETENTION_DAYS environment variable. Set it to 0 to disable pruning and retain logs indefinitely.

For most deployments, the default 180-day retention keeps database size manageable. If you have a large team with heavy MCP/API usage and need longer retention, plan your Postgres disk allocation accordingly using the estimates above.

Monitoring

We recommend monitoring the following metrics after deployment to validate your sizing:

• Memory utilization: sustained usage near the limit suggests you should scale up memory. High memory usage is expected and healthy since the OS page cache will use available memory.
• CPU utilization: sustained high CPU during searches (not just during indexing) indicates you may need more cores.
• Disk usage: monitor disk consumption as you add repositories. Running out of disk will cause indexing failures.
• Search response times: if searches are consistently slow, try increasing memory first, then CPU.