Deployment sizing
Self-hosted · your own hardware
What this actually needs to run.
Repository count, active users and CI clone rate decide the shape. Set them here and the specification follows. Switch to Enterprise Cloud to map seats onto the published tiers instead.
01Calculator
Recommended shape
Two nodes, HA pair
Estimated peak concurrency fits one node, so the second exists for availability rather than capacity — you can lose a node during business hours without a maintenance window.
- Note: Figures assume typical source repositories on SSD-backed storage.
- Nodes
- 2
- Gunicorn workers
- 17 total, 12 per node
- vCPU per node
- 14
- RAM per node
- 32 GB
- Estimated peak
- 50 concurrent requests
- Repository storage
- 500 GB + growth
- Database
- PostgreSQL, 4 vCPU / 16 GB
- Shared storage
- Required for repository data
- Search index
- Separate volume, ~75 GB
Assumes typical source repositories. Large binary histories, Git LFS at volume or a CI fleet cloning on every commit will push memory and storage well past these figures — tell us and we will size it properly.
02Next
What to do with these numbers
A calculator gets you to a purchase order, not to a running instance. These are the three things worth doing before you commit hardware.
02.1
Measure your real peak
Concurrency at 09:00 on a Monday is the number that matters, not the daily average. Pull it from your current server first.
One week of logs
02.2
Separate CI from people
Build agents cloning on every commit dominate load. Give them a read-only mirror or a cache and the node count usually drops.
Biggest single lever
02.3
Have us check it
Send the numbers and your VCS mix. We size deployments for a living and would rather correct the plan than the invoice.
sales@rhodecode.com