ServerMind
Star on GitHub Install
Use case · Safe database operations

Ask your production database, read-only

"How many active orders?" "How many signups today?" The answer is one SQL query away — but you don't want a teammate (or an AI) writing arbitrary SQL against production. ServerMind lets you ask in plain English and runs only a validated, read-only query.

The problem

Everyone wants a number from prod. Nobody should be writing freehand SQL to get it.

"Quick question — how many orders shipped today?" turns into someone opening a SQL client against the production database. That's a recipe for an accidental UPDATE without a WHERE, a long-running query that locks a table, or credentials sitting in a desktop tool. Lock it down too hard and every metric becomes a ticket for the one person with access.

You want the convenience of asking a question and getting a number, without ever granting a path to change the data.

How ServerMind helps

From the dashboard's Tools tab you can add database tools in two shapes — and the AI can only ever read:

  • A read-only DB query — a frozen SQL statement you write and the AI can only trigger. Perfect for a recurring metric like "open tickets" or "today's revenue".
  • A DB console — the AI writes a read-only SELECT at call time against a database you configured, so you can ask freely in plain English. The query it writes is validated before it runs.
How many active orders? How many signups today? Top 5 products by revenue this week Are there users with no email set? Count failed jobs in the last hour

Works with MySQL/MariaDB and PostgreSQL. Ask the question; get the answer — no SQL client, no copy-pasting credentials.

Read-only, enforced three ways

"Read-only" here isn't a polite request to the AI — it's enforced in depth:

  • Statement gate. Only SELECT/SHOW/EXPLAIN-class single statements are allowed. It blocks the classic exfiltration and write vectors — INTO OUTFILE, LOAD_FILE, COPY … PROGRAM, pg_read_file.
  • Engine-enforced read-only. On PostgreSQL the query runs inside a read-only transaction that rejects any write — including sneaky data-modifying CTEs.
  • Least-privilege grants. The strongest boundary is the database itself: point the tool at a dedicated SELECT-only role, and even a worst-case prompt can't exceed what that role is granted.

Connection passwords are encrypted at rest with AES-256-GCM and masked in the API. And like every change in ServerMind, a mutating command elsewhere still sits behind the server-side arm switch — but for these database tools, writing simply isn't on the table.

Why teams use it

  • Self-service metrics, safely. Anyone with a login can ask for a number without touching a SQL client or holding prod credentials.
  • No new attack surface. ServerMind itself has no SQL/ORM and no app database — settings are a JSON file and sessions live in memory — so there's nothing extra to SQL-inject.
  • Plain-English, real answers. The DB console turns a question into a validated SELECT, so non-SQL teammates get accurate numbers from the source of truth.
In one lineAsk production anything; ServerMind will only ever read the answer back.

FAQ

Can the AI write to or delete data?

No. A statement gate allows only read-class single statements, Postgres runs them in a read-only transaction, and a least-privilege SELECT-only role is the hard boundary.

How is a DB console different from a fixed query?

A fixed query is frozen SQL you define and the AI only triggers. A DB console lets the AI write a read-only SELECT at call time — validated by the same gate before it runs.

Are the credentials safe?

Yes — connection passwords are encrypted at rest with AES-256-GCM and masked in the API, and the database role caps what's even possible.

Get started

$ curl -fsSL https://servermind.dev/install.sh | bash

See the custom tools guide for adding database tools step by step.

Related use cases: Startups without DevOps · On-call & incident response · Indie developers

← All use cases  ·  Read the setup guide →