Runs on your own box
Index Monitor is a scheduler and a database, not a crawler. Google does the indexing and the heavy lifting; your box just pulls the results down through the API and stores them. So it sits near-idle between hourly ingests - and runs happily on hardware you already own.
Why it barely registers
There is no crawler to run and no headless browser to feed. The appliance makes a batch of API calls on a schedule, writes the rows to its own database, and goes back to sleep. Here is where the memory actually goes on a single-agency box.
| Component | Typical RAM |
|---|---|
| Database (MariaDB) | 250–400 MB |
| Web app (PHP-FPM) | 150–300 MB |
| Ingest worker + scheduler | 100–200 MB |
| Nginx + Linux | ~200 MB |
| Comfortable in 2 GB · roomy on 4 GB | ≈ 1 GB |
Google crawls and indexes; the box only reads the verdicts back through the API. Nothing renders or fetches pages locally.
Ingest is async I/O - it spends its time waiting on Google and the database, not burning CPU. Near-zero load between the hourly runs.
Even the Pro tier’s full 16-month history for a handful of properties is hundreds of MB, not gigabytes. The tables stay small and the queries stay cheap.
Pick your box
Two cores and 4 GB of RAM is the comfortable target; 2 GB works for a single small site. Anything on this list clears it.
Zero to Running in 5 Minutes
On a supported x86-64 Linux host, install Docker and the Compose plugin. On Synology NAS, use the Package Center to install Container Manager after confirming its CPU architecture is supported by the published image.
Make a folder to hold your database and config. In your terminal, run mkdir gsc-appliance && cd gsc-appliance.
Use our Web Generator to instantly build your docker-compose.yml file. It securely sets up your passwords and environment without needing manual .env files. Save the output to your new directory.
Run docker compose up -d. The images will pull, the database will initialize, and migrations will run automatically. In about 30 seconds, your self-hosted Search Console warehouse is live.
When the drawer box stops being enough
If you keep adding properties, retain years of history, or run heavyweight exports regularly, the first scaling move is not a Kubernetes detour. It is usually just relocating the database onto a roomier or managed host while the app, worker, and cron keep running exactly as they are.
Let the appliance keep polling Google while a bigger database host handles storage growth, longer retention, and heavier export workloads.
A dedicated or managed MariaDB box usually gives you snapshots, replication, and backup tooling that are awkward on a small local host.
The product shape stays the same. You point the appliance at a different DB host and carry on.
small installeverything on one local boxnext stepapp + workers local, MariaDB on a stronger hostPut the old laptop to work
Five properties free, forever. Dust off whatever you have, run one command, and start accumulating the history Google would otherwise delete.