Hardware & System Prerequisites Markdown Table Template
A system requirements table answers “will it run here?” before anyone downloads, provisions, or buys anything. It is the first thing an administrator checks when evaluating self-hosted software, the page IT procurement copies into a purchase request, and the reference support staff point to when a crash turns out to be a 512 MB VM. For a Docker image or an installable service, it is often the difference between a smooth trial and a support ticket on day one.
Edit This Template
Edit cells, add rows, or sort — the Markdown updates livePaste cells from Excel or Google Sheets into the first header to replace the table · Tab / Enter / arrows move · Shift+F10 opens row & column actions
When to Use This Table
The two specification columns serve different decisions. Minimum is the floor: the smallest machine on which the software starts, passes its smoke test, and handles a light workload. Recommended is a sizing statement for a stated workload — so many users, so much data — and it is only meaningful if that workload is written down. The Verification Command column turns the table into a checklist: an administrator can confirm each row in seconds, and support can ask for the output instead of a description.
Good requirement tables are measured, not guessed, and they say what the numbers assume. They name CPU architectures explicitly, keep operating systems and runtimes inside their vendors’ support windows, and include disk growth as well as install size. Weak ones copy figures from another product, describe hardware cloud users cannot choose, such as memory generation, or list commands that only work on one of the operating systems they claim to support.
What Goes in Each Column
| Column | Alignment | What to put here |
|---|---|---|
| Component | left :--- | The resource being specified — CPU, memory, disk, operating system, runtime, network — in plain words. One resource per row; if disk needs both capacity and speed, split them so neither number hides inside the other. Order rows from hardware to software. |
| Minimum Specification | left :--- | The measured floor, with units and architecture: 1 vCPU (x86_64 or arm64), 1 GiB RAM. State what “minimum” covers, such as a single user with demo data. Software versions belong here as ranges (>= 22.12) that match what the installer or engines field actually enforces. |
| Recommended Production Spec | left :--- | What you would provision for the workload described under the table, in the units buyers use: vCPUs, GiB, disk type and size, or an example instance size. Name OS releases that are inside standard support, and the runtime’s current LTS line. |
| Verification Command | left :--- | A read-only command that prints the value in question, in backticks. Give one per operating system where they differ, because free and lscpu do not exist on macOS. Prefer commands that need no extra packages and no root privileges. |
How to Fill It In
- 1Find the real minimum by running the software in a constrained container, for example
docker run --cpus=1 --memory=1g ..., then executing your smoke test and a typical workload. Watchdocker statsand record peak memory, not the idle figure. - 2Size the recommended spec with a load test at the workload you will state in the table, and leave headroom for traffic spikes, background jobs, and upgrades running alongside normal load.
- 3Measure disk in three parts: the installed footprint (
du -sh), growth per unit of use (per thousand records, per day of logs), and temporary space for backups, image pulls, and migrations. - 4Take operating system and runtime floors from upstream support lists. Node.js 24, for example, documents macOS 13.5 or later and Linux with glibc 2.28 or later, so your own floor cannot be lower.
- 5Run every verification command on every operating system you list, from a non-admin account, and paste the real output into your notes.
Ready-to-Paste Variations
Verification commands per operating system
A companion table for docs that support Linux, macOS, and Windows. Every command is read-only.
| Check | Linux | macOS | Windows (PowerShell) |
| :--- | :--- | :--- | :--- |
| Logical CPUs | `nproc` | `sysctl -n hw.ncpu` | `$env:NUMBER_OF_PROCESSORS` |
| Total memory | `free -h` | `sysctl -n hw.memsize` (bytes) | `(Get-CimInstance Win32_ComputerSystem).TotalPhysicalMemory` |
| Free disk | `df -h /var/lib` | `df -h /` | `Get-PSDrive C` |
| OS version | `cat /etc/os-release` | `sw_vers` | `Get-ComputerInfo -Property OsName, OsVersion` |
| CPU architecture | `uname -m` | `uname -m` | `$env:PROCESSOR_ARCHITECTURE` |Sizing tiers by workload
Illustrative tiers for a hypothetical self-hosted web app. Replace the numbers with your own load-test results, and keep the workload column, because it gives the other numbers their meaning.
| Tier | Workload | vCPU | Memory | Disk |
| :--- | :--- | ---: | ---: | :--- |
| Evaluation | 1–5 users, demo data | 1 | 1 GiB | 5 GB SSD |
| Team | Up to 100 users | 2 | 4 GiB | 50 GB SSD |
| Department | Up to 1,000 users | 4 | 16 GiB | 200 GB SSD; separate database host |Network requirements
Firewall and proxy teams need direction, port, and destination. A bare “port 443” answers none of their questions.
| Direction | Port / protocol | Peer | Purpose |
| :--- | :--- | :--- | :--- |
| Inbound | `443/tcp` | Users’ browsers | HTTPS web interface |
| Outbound | `443/tcp` | `updates.example.com` | Update checks and licence validation |
| Outbound | `5432/tcp` | Database host | PostgreSQL, if not on the same machine |
| Outbound | `123/udp` | NTP servers | Clock sync; signed tokens fail when clocks drift |Common Mistakes
Allowing
arm64in the minimum but requiring AVX2 in the recommended spec.AVX2 is an x86 instruction set extension, so the two rows contradict each other. State instruction-set needs per architecture. Also note that some virtual machines hide AVX2 from guests by default; on Linux,
grep -m1 -o avx2 /proc/cpuinfoconfirms it is visible.Listing runtimes and operating systems that are already end-of-life.
Node.js 18 reached end of life in April 2025 and Node.js 20 in April 2026. Set the floor at a supported LTS line and recommend current OS releases such as Ubuntu 24.04 LTS or Debian 13.
Describing hardware details cloud customers cannot choose, such as “ECC DDR4”.
Express requirements as vCPUs, memory in GiB, and disk type, size, and IOPS. Mention ECC or specific hardware only for on-premise appliances where the buyer really picks the parts.
Quoting disk space for the install alone.
A 500 MB install with a database that grows 2 GB a month needs a growth line. Give a rate per unit of use and the free space required during upgrades and backups.
Using a real company’s hostname in an example command.
Use the reserved
example.comdomains for placeholders, as incurl -I https://api.example.com, so nobody accidentally probes a live server they do not own.
Related Markdown Table Templates
Browse all 50 templatesCron Job Schedule Syntax Reference
Cheat sheet for 5-field crontab scheduling expressions, field ranges, special wildcard characters, and human frequency interpretations.
Security Advisory & CVE Vulnerability Matrix
Track security advisories, CVE identifiers, CVSS v3 ratings, affected library versions, patched releases, and remediation guidance.
CI/CD Pipeline Stages & Automation Gates
Document multi-stage CI/CD workflows across linting, unit testing, security scanning, container builds, and production deployments.
Hardware & System Prerequisites: Frequently Asked Questions
Is a vCPU the same as a CPU core?
Often not. On many x86 cloud instance types a vCPU is one hardware thread, so 4 vCPUs equal 2 physical cores with hyper-threading. On AWS Graviton instances, each vCPU is a full physical core. For CPU-heavy software, state which one you tested on.
Should I write GB or GiB?
Memory is sized in binary units, and tools like free -h print Gi, so GiB is the accurate unit for RAM. Disk vendors sell decimal gigabytes. The difference is about seven percent at this scale, enough to matter on a tight disk.
How do requirements apply when the software runs in Docker Desktop?
On macOS and Windows, containers run inside a virtual machine, and they only see the CPU and memory assigned to that VM: in Docker Desktop’s resource settings on macOS, or in .wslconfig when Windows uses the WSL 2 backend. A laptop with 16 GiB can still give the container too little. Say this in the table notes.
Do I need separate tables for development and production?
Usually, yes. Developers need compilers, a container runtime, and extra memory for watchers and test runners; production needs none of that but has stricter OS, network, and storage requirements. Two short tables are easier to scan than one with mixed rows.