What is read-only in DevOpsPad
The database and cluster query workspace in DevOpsPad is read-only. Each engine is restricted in its own way, from server-side read-only modes to command allowlists. These restrictions are a safety net, not a security boundary: the account you connect with decides what is really possible, so use read-only accounts.
Changes to clusters happen only in the Infra console, through a separate write path that shows you a plan before anything is applied.
How each engine is restricted
| Engine | Mechanism | What it blocks |
|---|---|---|
| MySQL | Each query runs in a server-side READ ONLY transaction that is always rolled back |
INSERT, UPDATE, DELETE on regular tables. Not DDL: see below |
| ClickHouse | Every request is sent with readonly=1 |
Writes and settings changes, enforced by the ClickHouse server |
| MongoDB | Only a JSON find is accepted |
Everything except reading a collection |
| Redis | Command allowlist of 20 commands | Every other command |
| Kafka | Metadata requests only | Producing and consuming messages, admin operations |
| Kubernetes / K3s | Only get <resource> [namespace], plus get, events and logs in the inspector |
Every write verb |
The Redis allowlist is: GET, MGET, GETRANGE, LRANGE, XRANGE, TYPE, TTL, PTTL, SCAN, HSCAN, SSCAN, ZSCAN, HGET, HLEN, LLEN, SCARD, ZCARD, DBSIZE, INFO and PING.
The MySQL DDL gap
MySQL commits DDL statements such as DROP TABLE, ALTER TABLE, CREATE TABLE and TRUNCATE implicitly. They end the current transaction and run outside it, so a read-only transaction does not reliably stop them. If your MySQL user has DDL privileges, a DDL statement typed or pasted into DevOpsPad can run.
The real guarantee is the account: connect with a user that has only SELECT (and SHOW VIEW if you want view definitions). See Create least-privilege accounts.
Read limits are part of the design
Results stop at 500 rows or documents and 8 MiB, logs at 2,000 lines and 256 KiB, and queries time out after 20 seconds. That keeps a desktop client from becoming a bulk export tool. See Why results stop at 500 rows.
AI suggestions never run on their own
The AI assistant can only place text in the editor. You decide what runs. See Insert an AI suggestion into the editor.
Where DevOpsPad does write
The Infra console has its own write path, separate from the query adapters:
- Deployments: release an image, roll back to a previous release, scale and restart existing Deployments. Each action builds a plan with a Kubernetes server-side dry-run, which you review and confirm. Execution takes a per-Deployment Lease, re-checks the UID and
resourceVersion, waits for the rollout and writes a local record. See Release an image. - ConfigMaps: edits are saved only when you click save, after a syntax check, and only if the ConfigMap’s UID and
resourceVersionstill match. - Host Nginx config: when configured, a
.conffile under/etc/nginx/conf.d/can be edited over SSH; the change is tested withnginx -tand the original is restored if the test or reload fails.
StatefulSets and DaemonSets can be viewed but not changed. Nothing in DevOpsPad creates or deletes workloads.
What read-only does not cover
- Load on the server: a heavy
SELECTcan still slow a production database. Prefer replicas for exploration. - Data you copy out: exports and clipboard contents are outside DevOpsPad’s control.
- Permissions: DevOpsPad never grants access the server does not.
Frequently asked questions
Can DevOpsPad change data in my database?
The query workspace is designed to read only, but MySQL's read-only transaction does not stop DDL statements. Connect with an account that has only SELECT privileges to make writes impossible.
Which parts of DevOpsPad can change my cluster?
Only the Infra console. It can release an image, roll back, scale and restart existing Deployments, and save ConfigMap edits, each after you review and confirm.