Termalin

View saved version →

---
name: database-access
description: Explore and query databases on the user's servers (Postgres, MySQL/MariaDB, Redis, MongoDB, SQLite) through Termalin without credentials in the chat. Use when the user asks what is in a database, wants a query, a count, a schema, a slow query check or a data fix on a server.
---

Termalin's `data_*` tools connect to the database on the server through the Connector, so no password is ever pasted here. The default is read-only.

Order of work:

1. `hosts_list` to pick the server, then `data_tables` with the `engine` and `database` to see what exists. Do not guess table names.
2. `data_schema` for each table the question touches: columns, types, keys, indexes, row estimate. Use the real column names in the query.
3. `data_query` for the actual question. Rules:
   - Always add `LIMIT` (default 50, at most 500) to row-returning queries; aggregate with `COUNT`, `GROUP BY`, `date_trunc` instead of pulling rows and counting in the chat.
   - Read-only unless the user explicitly asks for a change. A write (`INSERT`, `UPDATE`, `DELETE`, `ALTER`, `DROP`, Redis `SET`/`DEL`, Mongo updates) needs `allowWrites: true`, a connection with full access, and the user's yes to the exact statement; show the statement first, with a `WHERE` that matches what they described, and prefer a `SELECT COUNT(*)` with the same `WHERE` before the `UPDATE`/`DELETE`.
   - Wrap risky writes in a transaction when the engine supports it, and report the affected-row count after.
   - Long analytical queries (over a minute) time out; narrow the date range or run them as a background job on the server with `job_start` and the engine's CLI.
4. Present results as a compact table or a sentence with the number; name the database and server the answer came from.

Privacy: do not dump whole tables of personal data (emails, names, addresses, payment fields) into the chat. Aggregate, or select only the columns the question needs, and mask identifiers when the user only needs a count or a pattern.

Slow database: `data_query` with the engine's own views — Postgres `pg_stat_activity` (running queries, waits), `pg_stat_user_tables` (seq scans), `pg_stat_statements` if installed; MySQL `SHOW FULL PROCESSLIST`, `SHOW ENGINE INNODB STATUS`; Redis `INFO memory`, `SLOWLOG GET 10`. Pair with `server_metrics` to see whether the host is CPU-, memory- or disk-bound.

View saved version →

---
name: deploy-check
description: Verify a server after a deployment, update or restart — services up, ports listening, logs clean, site answering, certificates valid, metrics stable. Use when the user says they just deployed, updated, restarted or migrated something and wants to know it is fine.
---

A deployment is good when the service is up, nothing new is in the error logs, the site answers and the numbers look like before. Check all four, read-only, and report in that order.

1. Services and ports (`ssh_exec`):
   - `systemctl --failed --no-pager` — must be empty.
   - `systemctl status <unit> --no-pager | head -5` for the deployed unit(s); for Docker: `docker compose ps` or `docker ps --format '{{.Names}} {{.Status}}'` — look for "Restarting" and recent restarts.
   - `ss -tlnp | grep -E ':(80|443|<app port>)'` — the expected ports are listening.
2. Logs since the deploy:
   - `journalctl -u <unit> --since '-15 min' -p warning --no-pager | tail -50`, or `docker logs --since 15m <container> 2>&1 | grep -i -E 'error|fatal|panic|exception' | tail -30`.
   - Web server: `tail -50 /var/log/nginx/error.log` (or the equivalent).
3. From the outside: `curl -s -o /dev/null -w '%{http_code} %{time_total}s\n' https://<domain>/` and one real endpoint (`/health`, `/api/...`). A 200 with the previous latency is the goal; a 502/503 means step 1 lied — go back.
4. Certificate and monitoring:
   - `echo | openssl s_client -connect <domain>:443 -servername <domain> 2>/dev/null | openssl x509 -noout -enddate`.
   - `server_metrics` for the host with `hours: 2`: CPU, memory and load should settle within minutes; a climbing memory line after a deploy is a leak or a missing cache limit, say so.
   - `alerts_list`: nothing new for this host.

Report as a short checklist with ✓ / ✗ per item and the evidence (one line each). If anything failed, give the most likely cause and the first rollback or fix step, but do not perform it without the user's yes. If a migration or build is still running, follow it with `job_status` instead of re-running it.

View saved version →

---
name: incident-triage
description: Work through a server alert or outage step by step — disk full, high load, service down, OOM, certificate expiring, server offline. Use when the user pastes an alert, says something is down or slow, or asks why a server misbehaves.
---

Triage in a fixed order, read-only first, and stop to ask before any change.

## 1. Frame it

- Which server? Resolve the name with `hosts_list`. If the alert came from Termalin, `alerts_list` has the current state and when it started.
- Pull `server_metrics` for that host with `hours: 24` to see the trend: a disk that fills steadily and a disk that jumped are different problems.

## 2. Look, with read-only commands

Run these with `ssh_exec` as needed; they change nothing:

- Disk: `df -h`, then `du -xsh /var/log /var/lib/docker /home /tmp 2>/dev/null | sort -h`, `journalctl --disk-usage`, `docker system df` if Docker is there.
- Memory / OOM: `free -m`, `ps aux --sort=-%mem | head -15`, `dmesg -T | grep -i -E 'oom|killed process' | tail -20`.
- Load / CPU: `uptime`, `top -bn1 | head -25`, `ps aux --sort=-%cpu | head -15`, `iostat -x 1 3` or `vmstat 1 5` when I/O is suspected.
- Service down: `systemctl status <unit> --no-pager -l`, `journalctl -u <unit> -n 100 --no-pager`, `ss -tlnp` to see what is actually listening.
- Server offline per Termalin but the user says it is up: the Connector itself may be down; check `systemctl status termalin-agent` from another path or ask the user to look at the machine.
- Certificate: `openssl x509 -in <path> -noout -enddate`, and whether a renewal timer exists: `systemctl list-timers | grep -i -E 'certbot|acme'`.
- Website slow: `curl -s -o /dev/null -w '%{http_code} %{time_total}s' https://<domain>/`, then the web server and app logs.

Keep output short: use `tail`, `head`, `-n`. Anything that could run longer than a minute goes through `job_start` and `job_status`, not `ssh_exec`.

## 3. Explain

Give one paragraph: what is wrong, the evidence (numbers, log lines), the likely cause. Then a numbered plan, with the first step being the least destructive thing that stops the bleeding (rotate logs, clear a cache, restart one service) and the real fix after it.

## 4. Fix only with consent

Do not restart services, delete files, kill processes or change configs until the user says yes to the specific step. For deletion prefer the reversible form: `journalctl --vacuum-size=500M`, `apt-get clean`, `docker image prune -f` (not `-a` unless agreed). After each change, re-check the metric that triggered the alert and say whether it recovered.

Respect the connection's policy and the server note Termalin shows in the tool output; a read-only connection cannot perform fixes, say so instead of trying.

View saved version →

---
name: run-commands
description: Run shell commands and edit files on the user's servers through Termalin safely. Use whenever a task needs ssh_exec, ssh_exec_many, job_start, sftp_read or sftp_write — installing packages, editing configs, restarting services, tailing logs, running scripts on one or many servers.
---

Termalin runs each command on the user's own server through their Connector, authenticated with a short-lived certificate, and records it in their audit log. Treat every call as something the user will read later.

## Before running

- Start with `hosts_list` to get server ids and the connection policy (full access, allowlist or read-only) and the server note; follow the note, it is the owner's instruction for this machine.
- If there are no servers, do not improvise: tell the user to add one at https://termal.in/account (Add → Tunnel gives a one-line Connector install) and stop.
- Pick the login user: the Connector's default unless the user names another. Commands that need root go through `sudo` only when the policy and the user allow it.

## How to run

- One server, quick command: `ssh_exec`. Keep output bounded (`tail -n`, `head`, `--no-pager`, `-q`), the answer is cut at about 90 seconds of wall time.
- Longer than a minute (builds, migrations, backups, `apt-get upgrade`, large `rsync`): `job_start`, then `job_status` with `lines` to follow it, `job_stop` only on request. Report the job id so the user can ask about it later.
- The same command on several servers: `ssh_exec_many` with the ids, at most 10 per call, and report per server.
- Files: `sftp_read` before `sftp_write`, never overwrite blind. Writing a config: keep a copy first (`cp file file.bak-$(date +%F)` via `ssh_exec`), write, then validate (`nginx -t`, `sshd -t`, `apachectl configtest`, `postgres --check` equivalents, `docker compose config`) and reload only if the user asked for the reload.

## What not to do without an explicit yes

- Anything destructive or hard to undo: `rm -rf`, `dd`, disk formatting, `DROP`, `git push --force`, `reboot`, `shutdown`, firewall changes that could lock the user out, `apt-get remove` of a running stack, changing `sshd_config` or the Connector's own service.
- Printing secrets into the chat: environment files, private keys, `/etc/shadow`, password fields in configs, tokens in logs. If a task needs such a value, ask the user to provide it or to set it on the server themselves; never copy it into the conversation.
- Interactive commands (`vim`, `top` without `-bn1`, `less`, `apt` prompts): use non-interactive flags (`-y`, `DEBIAN_FRONTEND=noninteractive`, `--no-pager`).
- Guessing paths and unit names: look first (`ls`, `systemctl list-units | grep`), then act.

## After running

Say what ran, where, the exit code and the part of the output that matters. If a command failed, show the error and suggest the next step; do not retry blindly with `sudo` or `--force`.

View saved version →

---
name: server-health
description: Answer "how are my servers doing", "is everything up", "anything wrong with prod" from Termalin's monitoring data. Use when the user asks about server status, load, disk, memory, uptime or alerts, before running any command on a server.
---

Answer health questions from the data Termalin already collects, not by running commands.

1. Call `alerts_list` first. Open alerts are the headline: say what is wrong, on which server, since when.
2. Call `server_metrics` (no `host` for all servers, default 6 hours; set `hours` when the user names a period). It returns per-server CPU, load, memory, disk per mount, failed systemd units, listening ports, certificate expiry and offline state.
3. If the user asks about one server, give its name or id from `hosts_list`.

How to report:

- Lead with problems: offline servers, disks over 85 %, memory under 10 % free, load above the core count, failed units, certificates expiring within 14 days. If there are none, say so in one line and give the numbers in a compact table (server, CPU, load, memory, worst disk).
- Compare with the previous window when the data has it: "disk / grew 3 GB in 6 h" matters more than the current percentage.
- Metrics come from the Connector on each server; a server that reports nothing is either offline or has monitoring switched off in Termalin. Say which, do not guess.
- Only after reporting, offer the next step. If the user wants to dig in, use the `incident-triage` skill or a read-only `ssh_exec` (for example `df -h`, `free -m`, `systemctl --failed`, `journalctl -p err -n 50`) — never a command that changes state.

If `server_metrics` says monitoring is off or there is no data, tell the user to enable monitoring for that server in their Termalin account (Account → Monitoring) and that alerts only work when monitoring is on.