I built an open-source tool that shows your servers and databases as a living 3D city

Most infrastructure tools show you lists: servers, databases, alerts, all in rows. The problem with a list is that it re-sorts itself. When something goes wrong, you have to read it to find out what changed. So I built GRIDCITY: an open-source (MIT), local-first console where every server, database, Redis instance and bucket is a building in a 3D city. A city stays put. You remember where things are, so a change of light is the first thing you notice. Try it in your browser (simulated data): https://chapeee.github.io/GRIDCITY/demo/ Code: https://github.com/chapeee/GRIDCITY Rule one: every light means exactly one thing The thing I cared about most is that the picture never lies. Edge pulse speed is CPU. Light strips filling upward are memory. A segmented ring at the base shows each disk; an amber arc means that disk is nearly full. Particles rising around a tower are network throughput. An offline server is dark and motionless. A server whose data stopped arriving freezes, greys out and shows "last seen". Replay is always labelled REPLAY. Databases are drums, Redis is a hexagonal prism, buckets are low warehouses. A pretty view that shows a dead server as healthy is worse than no view at all, so "truth first" is the one principle I don't bend. It's not just a picture Looking at the city is the starting point. From there: Jack in: press Enter on a building for a real SSH terminal. Manage data: press M on a database for a SQL manager (PostgreSQL, MySQL/MariaDB, SQL Server, SQLite), a key browser and console for Redis, documents for MongoDB, and a file browser for S3, Spaces, MinIO and R2. Everything opens read-only, enforced by the database itself, until you click "Allow changes", and every change is audited. Security: SSH brute force, a login right after failed guesses, a new root account, a public bucket or a database open to the internet puts a red ring on the building. CrowdSec and Fail2ban findings show up too. Alerts with the app closed: browser push, email, Slack, Discord, Telegram, Teams, ntfy, Gotify, Pushover and Apprise. Time travel: press T and drag back to last night's incident, then press Play and watch it unfold. The Doctor: prove the fix before suggesting it "Could not connect" is the least helpful error in ops. When a connection fails, the Doctor climbs DNS → port → TLS → login, matches the real error against its rules, recognises managed providers, and then tries each candidate fix with a real read-only connection. You get something like "Turn on TLS: proven, connected with this change" instead of a guess. It also runs headless: gridcity doctor --json works in CI. Letting an AI near your servers, safely GRIDCITY is also an MCP server, so Claude Code, Cursor or any MCP client can call tools like incident_report (everything unhealthy, grouped by likely root cause), diagnose, get_topology and security_findings. The one tool that changes anything is run_command, and it never runs on its own. Every command the AI wants to run shows up as an approval card in the city: the exact command, the server, and the AI's reason. You click Allow or Deny. If a command needs a sudo password, you type it into the card, and it goes to the command, never to the model. npx gridcity # start it npx gridcity mcp # prints the command to connect Claude Code Private by design It runs on your machine and listens on 127.0.0.1 only. It connects outward over your existing SSH keys and installs nothing on your servers (one read-only script reads /proc and df). No cloud, no account, no telemetry. Credentials you paste are stored encrypted locally. Honest limits It's single-user and local by design. Remote servers must be Linux. It keeps days of history (7 by default, up to 90), so it is not a Prometheus or Grafana replacement. It catches known attack patterns, not every attack. It's v0.4, so expect rough edges. Try it npx gridcity demo # a simulated city, no setup at all or with Docker: docker run -d --name gridcity -p 127.0.0.1:4600:4600 \ -v gridcity-config:/config -v gridcity-data:/data ghcr.io/chapeee/gridcity I'd love feedback, especially on one question: does the city view actually help you spot problems faster than a list? Issues and ideas are welcome on GitHub: https://github.com/chapeee/GRIDCITY