Troubleshooting

Solutions for common connection, permission, configuration and update problems, with the exact error messages QueryGlow 1.3.0 shows.

Start Here

Run ./queryglow doctor in your QueryGlow directory. It checks Docker, .env, containers, health, versions, ports, nginx, DNS, the certificate and disk space, and names what is wrong. --fix applies four safe repairs.
Run ./queryglow status to see the installed and the running version.
Update first: ./queryglow update. Several errors below are fixed in 1.3.0.

Query Blocked

The Query Editor answers with one of these:

Blocked: Destructive operations (DROP, TRUNCATE, DELETE/UPDATE without WHERE) are disabled.Blocked: This operation is not allowed for security reasons.

The first one is Safe Mode (on by default)

It blocks DROP TABLE, TRUNCATE, dropping indexes, views, materialized views, sequences and schemas, and DELETE or UPDATE without WHERE.

To lift it (Power Mode)

Set QUERYGLOW_ALLOW_DESTRUCTIVE=true in your .env, then recreate the container (a plain restart does not read .env again):docker compose -f docker-compose.production.yml up -d --force-recreate queryglow

The second one is always blocked

DROP DATABASE, SHUTDOWN and SQL that runs commands on the server or moves data through files on it cannot be enabled. Use your database's own CLI for these.

Tip: the Data Browser's edit and delete buttons work regardless of Safe Mode; on a production connection a row delete asks you to type DELETE. The "Run on production?" dialog is a confirmation, not a block.

Connection Refused (ECONNREFUSED) or Timeout

QueryGlow cannot reach your database host. It waits at most 5 seconds for a database server, and 15 seconds for an SSH handshake.

Database on same server? Use localhost

Production deployments use network_mode: host, so localhost or 127.0.0.1 connects directly to your server. No special Docker hostname needed. Find local servers in the New Connection dialog shows what listens on the standard ports.

Check the database is running

Verify the database service is active:sudo systemctl status postgresqlOr for MySQL:sudo systemctl status mysql

Check the database listens on the right interface

PostgreSQL: listen_addresses in postgresql.conf must include localhost or *.

CockroachDB: use 127.0.0.1, not localhost

A timeout with localhost is usually an IPv6/IPv4 mismatch. Use 127.0.0.1.

SSH Tunnel Errors

The connection fails when you use an SSH tunnel to reach a remote database.

"All configured authentication methods failed"

The SSH server rejected the login. Check the SSH username, and paste the full private key including the BEGIN and END lines. Convert PuTTY .ppk keys with puttygen first. The key must be authorized on the server (ssh-copy-id, see Connections).

Encrypted key passphrase

If your private key is encrypted, enter the passphrase in SSH Passphrase (Optional). Leave it empty for unencrypted keys.

The database host should be localhost

With an SSH tunnel, set the database Host field to 127.0.0.1 or localhost: the tunnel ends on the remote server, so the database is local there.

Where is my key?

You can paste the key contents directly into QueryGlow, for example from cat ~/.ssh/id_rsa.

SSH Host Key Changed

Since 1.3.0 QueryGlow pins each SSH server's host key on first connect. A different key later is refused:

SSH host key for host:port has changed: pinned SHA256:..., presented SHA256:...

Not expecting a change? Stop here

If you did not reinstall or replace that SSH server, someone may be intercepting the connection. Compare the presented fingerprint with the one your server reports (ssh-keygen -lf on its host key).

Server reinstalled? Remove its pinned entry

The pinned keys live in ssh-known-hosts.json in the data volume. Remove the entry for that host and port, then connect again; the new key is pinned on that connection.

# On the server, in any directory: copy the file out of the data volume
docker cp queryglow:/app/data/ssh-known-hosts.json .

# Edit ssh-known-hosts.json: delete the entry whose host and port match
# the server you reinstalled, keep all other entries

# Copy it back and give it to the user QueryGlow runs as
docker cp ssh-known-hosts.json queryglow:/app/data/ssh-known-hosts.json
docker exec -u root queryglow chown -R nextjs:nodejs /app/data

Certificate Verification Failed (SSL)

A certificate error on a connection with Verify server certificate ticked.

Self-signed or private authority certificates are rejected

With the option on, the server certificate is checked against the publicly trusted authorities. Self-signed certificates and those from a provider's own authority (Amazon RDS, Google Cloud SQL) fail, and there is no setting for a custom CA. Untick Verify server certificate (the connection stays encrypted), or connect through an SSH tunnel with SSL off.

Connections saved before 1.3.0

MySQL and MariaDB connections saved before 1.3.0 verify by default. Edit such a connection and untick the option if its provider uses a private authority.

SSL required by the server

Tick Enable SSL/TLS connection; most cloud databases require it. If it still fails, check that the database accepts SSL connections from your server's IP.

Permission Denied (Database)

Connected, but tables won't load or queries fail.

PostgreSQL: grant schema access

The user needs USAGE on the schema:GRANT USAGE ON SCHEMA public TO my_user;GRANT SELECT ON ALL TABLES IN SCHEMA public TO my_user;

MySQL: host-specific users

MySQL users are defined by user@host. Make sure there is a user for my_user@'localhost' or my_user@'127.0.0.1'.

SQLite: Path Rejected or File Not Writable

SQLite database path must be inside the data directory (...). Copy the file there and use its full path, e.g. .../mydb.sqlite.

Security restriction: /app/data only

SQLite paths must resolve to a file inside /app/data, the Docker volume queryglow-data. You cannot open arbitrary paths on the server.

Copy your database into the data volume

docker cp keeps the file's owner (usually root); the second command lets QueryGlow write to it:

docker cp ./my-database.db queryglow:/app/data/my-database.db
docker exec -u root queryglow chown -R nextjs:nodejs /app/data

Then connect using /app/data/my-database.db.

AI Assistant Errors

"No API key configured for <Provider>. Add one under Ask AI > AI providers, or set <ENV> on the server."

Open Ask AI, click the gear (AI providers), paste your key and click Save, then Test. No restart needed. Or set OPENAI_API_KEY, ANTHROPIC_API_KEY or GOOGLE_API_KEY in .env and recreate the container:docker compose -f docker-compose.production.yml up -d --force-recreate queryglowA key in .env wins over the app, a placeholder too. Leave the AI key lines out or empty unless you use .env on purpose.

"'temperature' does not support 0 with this model" (OpenAI)

Fixed in 1.3.0: Ask AI no longer sets a temperature. Run ./queryglow update.

Rate limit exceeded (QueryGlow)

In standalone mode nginx limits Ask AI to 30 requests per minute per IP. Wait a moment and try again.

Rate limit exceeded (provider)

Your AI provider (OpenAI, Anthropic, Google) has its own rate limits. Check your API dashboard or plan.

Update Refused or Rolled Back

"This checkout has local changes to tracked files, so the update stops here."

A file that belongs to the repository was edited. The update fast-forwards to the newest release, which would fail or bury those changes. Keep or discard them, then update again:

git stash push -m 'before update'   # keep your changes (restore later: git stash pop)
git checkout -- <file>              # or discard them
./queryglow update

Everything configurable lives in .env, so no tracked file needs to be edited.

"Rolling back to ..." and "Rolled back: ... is serving again."

The new release failed its build, its health check or the version check, and the update returned to the release that ran before. Your app data was not touched. ./queryglow status shows the last update and its outcome, the receipt is in .queryglow/receipts/, and ./queryglow logs queryglow shows what the app said. Send ./queryglow doctor --report to support if it happens again. How updates work.

Agent Calls Refused: -32002 "Token paused by owner"

Resume the token

The token was paused in Agent Access (or with Pause all agents). Resume it there; the agent's client stays connected and needs no new setup. Agent Access.

Fixed in 1.3.0: Update First

JSON cells show [object Object]

JSON, JSONB and array values show as JSON text in 1.3.0, in the Data Browser and in query results, and editing them works.

Safari on iOS asks for the password a second time

Fixed in 1.3.0. In integration mode (your own nginx), also add the two icon blocks from the Docker guide to your site.

Saved queries fail to load

Since 1.3.0 a damaged saved-queries.json is reported as an error instead of being overwritten. Restore the app data from a snapshot with ./queryglow restore backups/<timestamp>; everything saved after that snapshot is lost.

Lost Connections After Update

SESSION_SECRET changed or lost

SESSION_SECRET encrypts stored database passwords and the AI keys saved in the app (AES-256-GCM). If it changes, they cannot be decrypted.Fix: restore your original .env from a snapshot with ./queryglow restore backups/<timestamp> --env (this also puts that snapshot's app data back), or enter the passwords and keys again.

Still stuck?

Check the container logs for detailed error messages:

./queryglow logs -fdocker compose -f docker-compose.production.yml logs -f queryglow

If that does not solve it, run ./queryglow doctor --report and send the output with the relevant log lines to [email protected], or contact support another way.