Requirements & sizing

Before you install RedScribe, here’s what it actually needs to run, and how to size the machine you put it on.

What you need

• Docker and Docker Compose. The normal way to run RedScribe (Installation Methods 1 through 3).
• Python 3 and a local Postgres, only if you’re working on RedScribe’s own code without Docker (Method 4).
• Node.js and npm, only if you need to rebuild a frontend bundle after changing its source yourself. This isn’t needed to run the app day to day, and isn’t part of the Docker image at all. See Frontend asset builds if that’s you.
• An existing Tailscale network, with MagicDNS and HTTPS certificates turned on, only for Method 1.

Sizing

Size RedScribe by how many people are actively using it at the same moment, not by how many accounts exist in total. Almost every request is quick, and the one thing that ties up real resources for a while is generating a report.

Tier	Active at once · total accounts	vCPU (min → recommended)	RAM (min → recommended)	Disk	Report jobs at once
Solo	1 user	1	1 → 2 GB	10 GB+	1
Pilot	up to 5 · up to 10	1 → 2	2 → 4 GB	20 GB	2
Small firm	10 to 15 · 10 to 30	2 → 4	4 → 8 GB	40 to 50 GB	2
Mid size firm	25 to 40 · 30 to 80	4 → 8	8 → 16 GB	100 GB+	3 to 4
Larger firm	50+ · 80 to 150+	8 → 16	16 → 32 GB	200 GB+	4 to 6

“Report jobs at once” is how many exports (PDF, DOCX, and so on) can run in the background simultaneously before the next one has to wait its turn, set from the Report Profiles page. See Reports & exports for what that limit actually protects.

These come from how the app actually behaves under load, not a formal load test, so keep an eye on how long report exports take on your largest engagement before committing to a tier. A single person kicking the tires can get by on even less than the Solo row, a 1 vCPU, 1 GB box, but that’s a floor for trying it out, not somewhere to stay once a second person or a report export joins in.

Past "Larger firm"

At that scale, stop scaling the box itself. The better move is splitting the database onto its own host and adding a background job queue, so report generation stops competing with ordinary browsing for the same limited resources. Neither of those exists yet as a built-in option, see Scaling & concurrency model for what that change would involve and why report generation is the first thing to run out of headroom.

What shifts these numbers

• Add RAM before CPU. Rendering a report spikes hardest on image-heavy findings, so if your team pastes in a lot of screenshots, bias toward more memory first.
• A shared host. These figures assume the app and its database share one machine, as shipped. Moving the database to its own host frees up headroom on both sides independently.
• Disk usage grows with stored evidence and how long you keep backups around, not with how much data is in the database schema itself.
• Engagements don’t contend with each other. At most two people are ever actively working the same engagement at once, by design, so total account count and how busy the system feels scale independently of each other.