DEV Community: Alex Kernel

7 Ways to Run a Server Security Audit Across a Fleet in Minutes (2026)

Alex Kernel — Thu, 18 Jun 2026 14:20:47 +0000

Running a server security audit across a fleet by hand is miserable: you open
twenty SSH sessions, paste the same grep into each, copy results into a
spreadsheet, and pray you didn't fat-finger a rm on a production box at 2 a.m.
This guide shows you how to sweep an entire mixed fleet — web, API and database
hosts across several OS families — for security problems in a single pass, in
strict read-only mode, using the open-source MCP server
remote-agents. The whole point
is that an audit literally cannot change anything: every host starts in plan
mode, so a compliance or incident sweep is safe by construction.

In short: put the whole fleet into read-only plan mode with set_mode,
then fan out one audit at a time — fleet_exec, fleet_read, fleet_search
and mapreduce — to check SSH hardening, file permissions, leaked secrets,
brute-force IPs and pending patches. Payloads are end-to-end encrypted
(AES-GCM-256); the relay only ever sees ciphertext, and a hard denylist for
paths like /etc/shadow holds even in bypass mode.

Architecture: ~20 hosts, one room
Installing agents and tagging the fleet
Why and when to run a fleet-wide audit
Quick summary table
Recipe 1 — Put the fleet in read-only plan mode
Recipe 2 — Find world-writable files and bad permissions
Recipe 3 — Audit SSH hardening across the fleet
Recipe 4 — Scan for leaked secrets and keys by content
Recipe 5 — Aggregate brute-force IPs with MapReduce
Recipe 6 — Check for pending security updates
FAQ
Wrapping up

Architecture: ~20 hosts, one room

Let's take a realistic mid-size production fleet — about twenty hosts split into
web, API and database tiers, with a couple of different OS families thrown in
because real fleets are never homogeneous. Every node runs a lightweight agent
that connects outbound to one encrypted relay room. The AI assistant (Claude
or opencode) sees the whole fleet as a single computer and addresses groups of
hosts by tag or OS family.

Host	Role	Tag	Stack
`web-1`, `web-2` …	Public web / reverse proxy	`web`	nginx, Ubuntu 22.04
`api-1`, `api-2` …	Application backends	`api`	Node.js, Debian 12
`db-1`	Primary database	`db`	PostgreSQL, Rocky Linux 9
(mixed)	Edge / build boxes	`os:macos`, `os:windows`	macOS / Windows

The magic is targeting. A single operation can hit the whole fleet
(target="all"), one tier (target="web" or target="api,db"), or one OS
family (target="os:linux"). That means a 20-host audit is one tool call, not
twenty SSH sessions — and results come back aggregated per host, so one
unreachable box never sinks the whole batch.

            ┌──────────────── AI (Claude / opencode) ────────────────┐
            │              remote-agents (MCP, stdio)                 │
            └────────────────────────┬────────────────────────────────┘
                                     │ wss:// (E2E AES-GCM-256)
                             ┌───────┴────────┐  relay (CF Worker or self-host)
                             │   room=fleet   │  (forwards ciphertext only)
        ┌──────────┬─────────┼──────────┬──────────────┬───────────┐
     web-1 web-2  api-1 api-2 …        db-1          mac/win edge
      (web)        (api)               (db)         (os:macos/windows)

Installing agents and tagging the fleet

On each host you install one Rust binary and start an agent with the right tag.
Tags are what make tier-wide audits possible, so be deliberate about them.

# once on every machine
npm i -g remote-agents

# web tier
remote-agents run --relay wss://<relay> --room fleet --token <secret> \
  --name web-1 --tags web
remote-agents run ... --name web-2 --tags web

# api tier
remote-agents run ... --name api-1 --tags api
remote-agents run ... --name api-2 --tags api

# database
remote-agents run ... --name db-1 --tags db

For 24/7 hosts, use remote-agents install instead of run — it registers a
background service (systemd on Linux, launchd on macOS) so the agent survives
reboots. To confirm the whole fleet is online, ask the AI "show me the agents in
the room"; under the hood that calls list_agents, which returns each peer's
OS family, distro, kernel, shell, tags and an update_available flag.

Note: The network is a flat peer mesh — there is no controller/agent
split. Your local machine joins as an equal peer and dispatches work. If you
want a send-only controller that never executes commands itself, start it with
--no-agent.

Why and when to run a fleet-wide audit

A fleet-wide security sweep is the kind of task that should be routine but
rarely is, because doing it manually scales linearly with host count. Here is
when this approach pays off the most:

Compliance & audit windows. SOC 2, ISO 27001 and PCI all want evidence that SSH is hardened, permissions are sane and patches are current — across every host, not a sample. Read-only plan mode produces that evidence without any chance of mutating the systems under review.
Incident response. After a suspected breach you need to know right now which hosts have world-writable files, leaked keys on disk, or a spike of failed logins. Twenty parallel greps beat twenty serial SSH sessions when the clock is ticking.
Drift detection. Configs rot. A host that was hardened six months ago may have had PasswordAuthentication flipped back during a debugging session.
Onboarding new servers. When you absorb a fleet you didn't build, a single audit pass tells you what you actually inherited.
Cross-platform reality. Real fleets mix Linux, macOS and Windows. os:<family> targeting lets one audit branch correctly per platform instead of failing half the hosts.

The recurring theme: you want to look, not touch. Everything below is built
around that guarantee.

Quick summary table

#	Recipe	What it does
1	Read-only `plan` mode	Locks the whole fleet so the audit cannot write anything
2	World-writable & bad perms	Finds `0002`-perm files and risky setuid binaries on every host
3	SSH hardening sweep	Checks `PermitRootLogin` / `PasswordAuthentication` fleet-wide
4	Secret scanning	Greps file content for AWS keys and private keys across hosts
5	Brute-force IP ranking	MapReduce over `auth.log` to rank top attacking IPs
6	Pending security updates	Lists upgradable packages per OS family (`apt` / `dnf`)

Recipe 1 — Put the fleet in read-only `plan` mode

Before you run a single audit command, lock the fleet down. Each agent has a
safety mode, and plan allows only safe reads — read_file, git_status
and non-mutating exec. Writes, overwrites and risky operations are simply
rejected. This is the foundation that makes a security audit safe for compliance
and incident work: a host in plan mode physically cannot be changed by the
sweep.

Step 1. Switch every host to plan. You set the mode per host with
set_mode. For a fleet, loop it over each agent (or ask the AI to apply it
to all of them):

set_mode  agent_id=web-1  mode=plan
set_mode  agent_id=web-2  mode=plan
set_mode  agent_id=api-1  mode=plan
set_mode  agent_id=api-2  mode=plan
set_mode  agent_id=db-1   mode=plan

Step 2. Confirm the lock with get_info. Don't take it on faith — read the
mode back from each host:

get_info  agent_id=web-1
get_info  agent_id=db-1

The get_info response reports the active mode, so you have proof every host is
read-only before the audit starts. That single field is exactly the kind of
artifact an auditor wants to see captured at the top of an evidence log.

Important: Even if a host were in bypass mode, a hard denylist for
sensitive paths like /etc/shadow and /boot still applies — those reads and
writes are refused unconditionally. plan mode is your first guardrail; the
denylist is the one that never comes off.

Recipe 2 — Find world-writable files and bad permissions

World-writable files are a classic privilege-escalation vector: any local user
can overwrite them, and if one happens to be a script run by root, you have a
problem. Auditing this by hand across twenty hosts is exactly the kind of busywork
that gets skipped — so let's do all of it in one command.

Step 1. Hunt for world-writable files fleet-wide. Use fleet_exec with
target="all". The find expression -perm -0002 matches anything with the
world-writable bit set; we prune the noisy virtual filesystems:

fleet_exec  target="all"
            command="find / -xdev -type f -perm -0002 -not -path '/proc/*' -not -path '/sys/*' 2>/dev/null | head -n 50"

Results come back per host, so you immediately see that, say, web-2 has a
stray world-writable file in /var/www while every other host is clean. One
slow or offline host doesn't block the rest of the batch.

Step 2. Audit setuid/setgid binaries. Unexpected setuid binaries are another
red flag. Same fan-out, different predicate:

fleet_exec  target="all"
            command="find / -xdev -perm -4000 -o -perm -2000 -type f 2>/dev/null | sort"

Step 3. Spot-check sensitive directories. For example, confirm that no SSH
private keys are group/world-readable:

# what fleet_exec runs on each host
find /home /root -name 'id_*' -not -name '*.pub' -perm /0077 2>/dev/null

Tip: Add -xdev (shown above) to keep find from descending into
network mounts and bind mounts — otherwise an NFS share can make the audit
crawl on every host that mounts it. Cap output with head so a misbehaving
box can't flood the per-host result back through the relay.

On macOS hosts the same find works but paths differ (/Users instead of
/home); on Windows you'd target os:windows separately with a PowerShell ACL
check rather than find. This is why OS-family targeting matters — more on that
in Recipe 6.

Recipe 3 — Audit SSH hardening across the fleet

SSH is the front door, so its config is the highest-value thing to audit. The two
settings that bite people most often are PermitRootLogin (should be no or
prohibit-password) and PasswordAuthentication (should be no if you're using
keys). Drift here is silent and dangerous.

Step 1. Read the raw config from every host. Use fleet_read to pull
/etc/ssh/sshd_config across the fleet in one shot:

fleet_read  target="os:linux"  path=/etc/ssh/sshd_config

You get the full file back per host, which is great for archival evidence. But
for a quick pass/fail you usually want just the relevant lines.

Step 2. Extract just the hardening-relevant directives. Switch to
fleet_exec and grep the effective values, ignoring comments:

fleet_exec  target="os:linux"
            command="grep -Ei '^\s*(PermitRootLogin|PasswordAuthentication|PubkeyAuthentication|X11Forwarding|PermitEmptyPasswords)' /etc/ssh/sshd_config || echo 'NONE SET (defaults apply)'"

The per-host output makes outliers jump out: if api-2 reports
PasswordAuthentication yes while the rest report no, you've found your drift.

Step 3. Check the running config, not just the file. Includes and drop-in
sshd_config.d/ files can override the main file, so verify what sshd actually
loaded:

fleet_exec  target="os:linux"
            command="sshd -T 2>/dev/null | grep -Ei 'permitrootlogin|passwordauthentication|pubkeyauthentication'"

Note: sshd -T prints the fully resolved effective configuration —
including drop-ins under /etc/ssh/sshd_config.d/. Auditing the main file
alone can miss an override that re-enables password auth. Because everything is
read-only, this is a perfectly safe command to run in plan mode.

On macOS, SSH config lives at the same path but is managed through
systemsetup -getremotelogin; remember to scope macOS hosts separately rather
than assuming the Linux command applies everywhere.

Recipe 4 — Scan for leaked secrets and keys by content

Secrets end up on disk far more often than anyone admits: an AWS key pasted into
a .env, a private key copied to the wrong host during a migration, a token in a
forgotten shell history. The right tool here searches by content, not just
filename, because attackers don't name files aws-key.txt.

Step 1. Search the fleet's content for AWS access keys. Use
fleet_search — it searches each host's files by content. AWS access key IDs
match a recognizable pattern:

fleet_search  target="all"
              content="AKIA[0-9A-Z]{16}"

Each match comes back with the host, file path and surrounding context, so you
know exactly which box and which file to rotate.

Step 2. Hunt for private key material. PEM-encoded private keys all start
with a tell-tale header:

fleet_search  target="all"
              content="BEGIN (RSA|OPENSSH|EC|DSA) PRIVATE KEY"

Step 3. Catch generic high-entropy tokens. For things like
password=, secret_key, or bearer tokens, a looser content search across the
fleet surfaces candidates worth a human review:

fleet_search  target="all"
              content="(api[_-]?key|secret|token|password)\s*[:=]"

fleet_search defaults to scanning sensible roots (home plus
Documents/Downloads/Desktop/Pictures), which is where stray credentials
usually land. For deployment configs under /etc or /srv, fall back to
fleet_exec with grep -rIE scoped to those directories.

Important: Treat the audit output itself as sensitive — it now contains the
very secrets you were hunting. The relay never sees plaintext (payloads are
AES-GCM-256 encrypted end-to-end and the relay forwards only ciphertext), but
the results land in your AI chat transcript. Rotate any key the scan finds; a
leaked key on disk should be considered compromised the moment you discover it.

Recipe 5 — Aggregate brute-force IPs with MapReduce

Individual hosts each see their own slice of a brute-force campaign. The
interesting question — which IPs are hammering the **whole fleet? — needs
cross-host aggregation. That's exactly what mapreduce is for: it partitions
the data across the fleet, runs a map_fn per partition, then folds everything
together with a reduce_fn.

Step 1. Map failed-password IPs per host. Each partition is a host's auth
log; the map step extracts the offending IPs and counts them locally:

mapreduce
  data=["web-1:/var/log/auth.log", "web-2:/var/log/auth.log", "api-1:/var/log/auth.log", "api-2:/var/log/auth.log", "db-1:/var/log/secure"]
  map_fn="grep 'Failed password' \"$(cut -d: -f2)\" | grep -oE 'from [0-9.]+' | awk '{print $2}' | sort | uniq -c"
  reduce_fn="awk '{c[$2]+=$1} END {for (ip in c) print c[ip], ip}' | sort -rn | head -n 20"

The map step does the heavy per-host counting in parallel; the reduce step merges
those partial counts and ranks the top 20 attacking IPs across the entire
fleet — a single ranked list instead of five logs you'd otherwise correlate by
hand.

Step 2. Make the run resilient. Add max_retries so a momentarily
unreachable host doesn't blow up the whole report:

mapreduce
  data=[ ... same as above ... ]
  map_fn="..."
  reduce_fn="..."
  max_retries=3

Failed partitions are automatically re-dispatched up to the retry limit, so a
box that hiccups gets a second (and third) chance rather than leaving a hole in
your data.

Tip: Different distros log SSH failures to different files —
Debian/Ubuntu use /var/log/auth.log, while RHEL/Rocky/Fedora use
/var/log/secure. Note how db-1 points at /var/log/secure above. If your
hosts use systemd-journald with no flat file, swap the map command's grep
for journalctl _COMM=sshd | grep 'Failed password'.

Once you have the ranked list, feeding the worst offenders into fail2ban or a
firewall denylist is a natural follow-up — but that's a write, so you'd
deliberately move the relevant host to edit mode first.

Recipe 6 — Check for pending security updates

Unpatched packages are the most common breach vector there is, and "are we
patched?" should be answerable in one command. The catch is that the answer
differs by OS, so this recipe leans hard on os:<family> targeting.

Step 1. List upgradable packages on Debian/Ubuntu hosts. Scope to the
relevant family and ask apt:

fleet_exec  target="os:linux"
            command="command -v apt >/dev/null && apt list --upgradable 2>/dev/null | grep -i security || true"

Step 2. Check RHEL-family hosts for security errata. dnf has a dedicated
security view:

fleet_exec  target="os:linux"
            command="command -v dnf >/dev/null && dnf updateinfo list security 2>/dev/null || true"

Guarding each command with command -v means a single target="os:linux" call
handles both Debian and RHEL hosts gracefully — the wrong tool simply no-ops
instead of erroring.

Step 3. Don't forget non-Linux hosts. macOS and Windows need entirely
different commands, so target them separately:

fleet_exec  target="os:macos"    command="softwareupdate -l"
fleet_exec  target="os:windows"  command="powershell -Command \"Get-WindowsUpdate\""

Note: This is a read-only check — none of the commands above install
anything, so they're safe in plan mode. When you're ready to actually
patch, that's a mutating operation: move the target hosts to edit (or
bypass) mode first, then run the upgrade. To find hosts running an outdated
agent binary, there's a dedicated tool — fleet_update_check — which flags
idle peers with a newer version available, after which you run
npm i -g remote-agents@latest on them.

That cross-platform split is the whole reason os: targeting exists: one logical
audit ("are we patched?") branches into the right command per platform instead of
failing on every host where the assumption doesn't hold.

FAQ

Is it really safe to run a security audit on production?

Yes — that's the entire design goal. You start every host in plan (read-only)
mode and confirm it with get_info, so the audit physically cannot write,
overwrite or delete anything. On top of that, a hard denylist for paths like
/etc/shadow and /boot applies even in bypass mode, and all command payloads
and results are end-to-end encrypted, with the relay forwarding only ciphertext.

How many servers can I audit in one command?

There's no fixed cap — fleet_exec, fleet_read, fleet_search and mapreduce
all fan out to as many hosts as match your target. A 20-host fleet is one
command instead of twenty SSH sessions, and results are aggregated per host
so you can read them like a report. One unreachable or slow host doesn't sink the
batch; with mapreduce you also get max_retries for transient failures.

How is this different from a dedicated scanner like OpenSCAP or Lynis?

It's complementary, not a replacement. Tools like Lynis and OpenSCAP run a fixed,
standardized benchmark on a single host. remote-agents is an interactive,
AI-driven layer that lets you run any check — including those scanners
themselves — across a whole fleet at once, correlate results, and pivot
instantly ("now show me which of those hosts also has password auth enabled").
You can even fleet_exec lynis audit system everywhere and aggregate the
scores.

Does the relay or any cloud service see my data?

No. Payloads are encrypted with AES-GCM-256 using a key derived from your room
token, and the relay — whether the Cloudflare Worker or a self-hosted Rust relay
(remote-agents-relay) — only ever forwards opaque ciphertext. You can run the
relay entirely on your own infrastructure and point agents at ws://your-host:8080,
so nothing leaves your environment.

Can I schedule the audit to run automatically?

Yes. Use schedule_add to register a 6-field cron job (sec min hour day month dow) directly on a host; it runs on the agent itself, so it keeps firing
even if the relay link drops. A nightly world-writable-file check or weekly SSH
config diff is a natural fit.

Wrapping up

A thorough server security audit across a fleet doesn't have to mean a day of
SSH tedium. With every host locked into read-only plan mode, one operator can
sweep twenty machines for world-writable files, SSH-hardening drift, leaked
secrets, brute-force IPs and missing patches — each in a single command, with
results aggregated per host and the worst offenders ranked automatically by
MapReduce. Because the work happens in plan mode behind a hard denylist and
end-to-end encryption, the same sweep that powers your incident response also
doubles as clean, repeatable compliance evidence — without ever risking the
systems under review.

Install: npm i -g remote-agents →
package on npm ·
source & documentation

Homelab Fleet Management with AI: 7 remote-agents Recipes (2026)

Alex Kernel — Thu, 18 Jun 2026 14:17:26 +0000

If your idea of homelab fleet management is currently five terminal tabs, a sticky note with IP addresses, and the dawning horror of remembering which Pi runs apt and which runs dnf — this guide is for you. We'll wire up a real mixed-architecture homelab (NAS, two Raspberry Pis, a Docker media box, and your desktop) so you can drive the whole thing from one AI chat instead of hopping between SSH sessions. The engine is the open-source MCP server remote-agents.

In short: a lightweight agent runs on every machine and dials outbound into an encrypted relay room. Your AI assistant (Claude or opencode) sees the whole homelab as one computer and calls tools like fleet_exec, fleet_read, schedule_add, exec, and set_mode. Command payloads are end-to-end encrypted (AES-GCM-256) — the relay only ever forwards ciphertext, never plaintext, never keys.

Architecture: five hosts, one room
Recipe 1 — Install agents and tag the homelab
Recipe 2 — One-command system updates across every Linux host
Recipe 3 — Nightly backups to the NAS that survive a relay outage
Recipe 4 — Whole-fleet health, disk, and temperature sweep
Recipe 5 — Docker management on the media host
Recipe 6 — Safe read-only inspection with plan mode and the denylist
FAQ
Wrapping up

Architecture: five hosts, one room

A homelab is rarely uniform. You've got x86 boxes, ARM boards, mostly Linux with maybe a stray macOS mini, and a wild mix of stacks. That heterogeneity is exactly what makes manual self-hosted server management painful — every host wants a slightly different incantation. Tags and OS-family targeting smooth that over: you address a group of machines in a single call, and the failures stay per-host instead of sinking the whole batch.

Here's the topology we'll use for the rest of this guide:

Host	Role	Tag	Stack
`nas`	Storage, backup target, shares	`storage`	TrueNAS / Linux, ZFS, NFS/SMB
`pi-1`	DNS / ad-block, light services	`pi`	Raspberry Pi (ARM64), Debian
`pi-2`	Sensors / home automation	`pi`	Raspberry Pi (ARM64), Debian
`media`	Jellyfin / Plex, Docker host	`media`	x86 Linux, Docker Compose
`desk`	Your main desktop / workstation	`workstation`	x86 Linux (or macOS mini)

Every agent joins the same relay room (say, homelab). It's a flat peer network — there's no controller node and no agent node, every machine joins as an equal peer that can both execute and dispatch. Tags let you fan out: target="pi" hits both Raspberry Pis, target="os:linux" hits every Linux box, and target="all" hits the entire fleet.

            ┌───────────── AI (Claude / opencode) ──────────────┐
            │            remote-agents (MCP, stdio)              │
            └──────────────────────┬────────────────────────────┘
                                   │ wss:// (E2E encrypted)
                           ┌───────┴────────┐  relay (CF Worker or self-hosted)
                           │   room=homelab  │
        ┌──────────┬───────┴────┬───────────┬──────────────┐
      nas         pi-1        pi-2        media           desk
   (storage)      (pi)        (pi)       (media)      (workstation)
    x86/ZFS       ARM64       ARM64      x86/Docker      x86 desktop

The neat part: that relay can be Cloudflare's hosted Worker, or your own self-hosted Rust relay (remote-agents-relay --bind 0.0.0.0:8080) running on the NAS itself. For a homelab that never wants to phone home to a cloud, self-hosting the relay keeps the entire control plane inside your own four walls.

Quick summary: the 6 recipes at a glance

#	Recipe	What it does
1	Install & tag	Put an agent on every host and tag it (`storage`, `pi`, `media`, `workstation`)
2	Fleet updates	Patch every Linux host with one `fleet_exec`; refresh the agents with `fleet_update_check`
3	Nightly backups	`schedule_add` a 6-field on-host cron that backs up to the NAS even if the relay drops
4	Health sweep	`fleet_exec` `df -h` / `sensors` / `uptime` with per-host results across x86 and ARM
5	Docker	`exec` `docker compose pull && up -d` and prune on the `media` host
6	Safe inspection	`plan` mode for read-only audits, plus the E2E + denylist guarantees

Why manage a homelab fleet this way

Before the recipes, it's worth being honest about when this approach earns its keep — and when it doesn't. Reach for AI-driven homelab automation when:

You're tired of SSH hopping. Patching five hosts by hand is five logins, five sudo prompts, and at least one "wait, was that the Pi or the NAS?" moment. One fleet_exec replaces all of it — roughly one command instead of N SSH sessions.
Your hardware is mixed. ARM Raspberry Pis and x86 boxes need different package managers and report sensors differently. OS-family targeting (os:linux) and tags let one request adapt per host without you branching by hand.
You want unattended, resilient automation. Scheduled backups should fire even if your laptop is closed and the relay is unreachable. On-host cron via schedule_add keeps running locally regardless of link state.
You want a single audit surface. A read-only plan-mode sweep across the whole fleet gives you a snapshot of every machine's disk, temperature, and uptime in one shot — perfect for the weekly "is anything quietly dying?" check.

It's not a replacement for Ansible playbooks or a Kubernetes orchestrator. Think of remote-agents as interactive plus autonomous access to shell, files, git, and cron across many hosts through one AI interface — ideal for small-to-medium fleets, dev/lab environments, and ad-hoc operations.

Recipe 1 — Install agents and tag the homelab

Everything starts with putting an agent on each box and giving it a tag. The package is a single Rust binary, so install is the same everywhere — only the --name and --tags change per host.

Step 1. Install and run on each machine. On 24/7 hosts like the NAS and the media box, use remote-agents install so the agent comes back as a background service (systemd on Linux, launchd on macOS) after a reboot. On the Pis and desktop you can do the same, or just run it interactively while you experiment.

# once on every machine
npm i -g remote-agents

# NAS — 24/7, install as a background service
remote-agents install --relay wss://<relay> --room homelab --token <secret> \
  --name nas --tags storage

# the two Raspberry Pis (ARM)
remote-agents install ... --name pi-1 --tags pi
remote-agents install ... --name pi-2 --tags pi

# Docker media host
remote-agents install ... --name media --tags media

# your desktop / workstation
remote-agents run ... --name desk --tags workstation

Step 2. Confirm the whole fleet is online. In your AI chat, just ask:

"Show me the agents in the homelab room."

Under the hood that calls list_agents, which returns each peer's OS family, distro, kernel, shell, tags, and an update_available flag. This is your inventory — in one response you can see that pi-1 and pi-2 report aarch64/Debian while nas and media report x86_64, which is exactly the kind of detail that decides whether you use apt or dnf later.

Tip: Resolution order for settings is CLI flag > REMOTE_AGENTS_* env > config.toml > default. For 24/7 hosts, drop the relay/room/token into config.toml so the systemd unit stays clean and secrets aren't baked into the command line.

Recipe 2 — One-command system updates across every Linux host

This is the headline win for homelab fleet management: patching the entire fleet in a single call instead of logging into each box. Because your hosts span Debian-based Pis and possibly an RPM-based NAS, you'll target by OS family and let each host run its own package manager.

Step 1. Patch every Linux host at once. The target="os:linux" selector hits nas, pi-1, pi-2, media, and desk (if it's Linux) in one shot. Use a command that works regardless of distro by trying both managers:

fleet_exec  target="os:linux"
            command="(command -v apt-get >/dev/null && sudo apt-get update && sudo apt-get -y upgrade) || (command -v dnf >/dev/null && sudo dnf -y upgrade)"
            timeout_ms=600000

Results come back per host: pi-1 and pi-2 report their apt upgrade, the NAS reports its own, and if one box is offline the others still complete — one failing host does not sink the batch. The Raspberry Pis, being ARM, pull arm64 packages while the x86 boxes pull amd64; you don't have to think about it, each host resolves its own architecture.

Note: Bump timeout_ms for upgrades — a big apt upgrade on a first-gen Pi over a slow SD card can easily run past the default. 600000 ms (10 minutes) is a safe ceiling for a homelab.

Step 2. Update the agents themselves. Software that manages your fleet should keep itself current. fleet_update_check reports which idle hosts are running an older version:

fleet_update_check

Then refresh the ones that are behind:

fleet_exec  target="all"  command="npm i -g remote-agents@latest"

Important: fleet_update_check deliberately only flags idle hosts. A host mid-task won't get yanked out from under a running job — you can patch it on the next pass.

Recipe 3 — Nightly backups to the NAS that survive a relay outage

Backups are the one job you absolutely cannot have depend on your laptop being awake. The trick here is schedule_add, which installs a cron job that runs on the host itself — so it fires every night even if the relay link is down, your AI client is closed, or your internet is out.

Step 1. Schedule a nightly pull from a Pi to the NAS. The cron spec is a 6-field string (sec min hour day month dow), which is one field more than classic crontab — the extra leading field is seconds. For 02:30 every night that's 0 30 2 * * *:

schedule_add  agent_id=pi-1  name=nightly-backup
              cron="0 30 2 * * *"
              command="rsync -aH --delete /home/pi/data/ nas:/mnt/tank/backups/pi-1/"

Step 2. Do the same for the other Pi and the media box, pointing each at its own folder under the NAS backup pool:

schedule_add  agent_id=pi-2   name=nightly-backup  cron="0 35 2 * * *"  command="rsync -aH --delete /home/pi/data/ nas:/mnt/tank/backups/pi-2/"
schedule_add  agent_id=media  name=config-backup   cron="0 40 2 * * *"  command="tar czf - /srv/docker | ssh nas 'cat > /mnt/tank/backups/media/docker-configs.tgz'"

Staggering the start times (02:30, 02:35, 02:40) keeps three machines from hammering the NAS at the same second. The backups land in ZFS-backed storage on TrueNAS, so you can layer snapshots on top for point-in-time recovery.

Step 3. Verify what's scheduled. List and prune jobs at any time:

schedule_list    agent_id=pi-1
schedule_remove  agent_id=pi-1  name=nightly-backup

Tip: Because the schedule lives on the host, a schedule_add you set today keeps running even if you never open your AI chat again. Treat schedule_list as your "what cron jobs did past-me set up?" audit — run it across hosts occasionally so nothing becomes a forgotten mystery.

Recipe 4 — Whole-fleet health, disk, and temperature sweep

Once a week, you want a single answer to "is anything in my homelab quietly dying?" One fleet_exec gives you disk usage, temperature, and uptime from every host, with results grouped per machine.

Step 1. Disk usage across the whole fleet. Free space is the classic silent killer — a full / will brick a Pi and stall Docker on the media box:

fleet_exec  target="all"  command="df -h / /mnt 2>/dev/null"

Step 2. Temperatures, accounting for x86 vs ARM. This is where the architecture split matters. On x86 boxes (nas, media, desk) the standard tool is sensors from lm-sensors. On the ARM Raspberry Pis, sensors often returns nothing useful — the canonical reading comes from vcgencmd instead. A command that adapts on each host:

fleet_exec  target="all"
            command="(vcgencmd measure_temp 2>/dev/null) || (sensors 2>/dev/null | grep -iE 'temp|core' | head -n 5) || echo 'no temp sensor'"

The Pis will answer with something like temp=48.3'C from vcgencmd, while the x86 hosts answer with Core 0: +42.0°C from sensors. You get one tidy per-host readout despite two completely different sensor stacks.

Step 3. Uptime and load to spot the limpers:

fleet_exec  target="all"  command="uptime && free -h | head -n 2"

Note: ARM Raspberry Pis and x86 hosts report differently almost everywhere — package managers, sensors, even the meaning of high load (a four-core Pi saturates faster than a desktop). When a per-host result looks weird, check whether you're reading a Pi (os:linux + tag pi, aarch64) before you panic. Throttling on a Pi (throttled=0x... from vcgencmd get_throttled) is the homelab equivalent of a check-engine light.

If you'd rather get the disk sweep separately for just the storage tier, swap target="all" for target="storage" and you'll only hit the NAS.

Recipe 5 — Docker management on the media host

The media box runs your Jellyfin/Plex stack under Docker Compose. Container lifecycle is a great fit for plain exec scoped to that single host — no need to fan out a fleet operation for a box-specific job.

Step 1. Pull updated images and recreate the stack. A pull followed by up -d is the standard zero-fuss update:

exec  agent_id=media
      command="cd /srv/docker/media && docker compose pull && docker compose up -d"
      cwd=/srv/docker/media
      timeout_ms=300000

docker compose up -d only recreates the containers whose images actually changed, so unchanged services (and your active Jellyfin streams) stay up. The pull can be chunky on a media stack, hence the generous 300000 ms (5-minute) timeout.

Step 2. Check container health and recent logs:

exec  agent_id=media  command="docker compose ps"
exec  agent_id=media  command="docker compose logs --tail 50 jellyfin"

Step 3. Reclaim disk after updates. Old image layers pile up fast on a media host. Prune them — but be deliberate about it:

exec  agent_id=media  command="docker image prune -f && docker builder prune -f"

Important: Plain docker system prune -af will also remove all unused images and can nuke volumes if you add --volumes. On a media host where you cache large images, prefer the narrower docker image prune -f shown above so you don't re-download tens of gigabytes on the next up. Let the AI propose the command in plan mode first (next recipe) and read it before you let it run.

Recipe 6 — Safe read-only inspection with plan mode and the denylist

You should never have to choose between "convenient" and "safe" on machines that hold your photos, backups, and home automation. remote-agents gives every host a safety mode you set with set_mode:

plan — read-only. Only read_file, git_status, and safe exec are allowed. Perfect for inspecting a host without any chance of changing it.
edit — writes allowed, and the agent makes an automatic backup before overwriting any file.
bypass — unrestricted access.
disabled — the agent rejects everything.

The natural homelab workflow is: inspect in plan, then flip to edit only for the moment you actually need to change something, then flip back.

set_mode  agent_id=nas  mode=plan     # look around, change nothing
# ... you've decided a config needs editing ...
set_mode  agent_id=nas  mode=edit     # writes now allowed, with auto-backup
# ... done ...
set_mode  agent_id=nas  mode=plan     # back to read-only

A read-only sweep pairs beautifully with this. Set the whole fleet to plan and ask the AI to report what it finds — it physically can't modify anything:

fleet_read  target="all"  path=/etc/os-release
fleet_search  target="storage"  query="zpool"

Two guarantees hold no matter what mode you're in. First, every command and result payload is end-to-end encrypted (AES-GCM-256, key derived from your room token) — the relay forwards ciphertext blind and never sees your data or keys. Second, a hard deny-list (paths like /etc/shadow and /boot) is enforced even in bypass mode, so an over-eager AI literally cannot read your shadow file or scribble in your boot partition.

Tip: For a recurring "is anything wrong?" audit, keep the whole fleet in plan mode by default and only promote a single host to edit for the exact window you're making a change. It turns a slightly scary AI-with-shell-access into a read-only dashboard that you consciously unlock.

FAQ

How is this different from Ansible or a dashboard like Cockpit?

It's complementary, not a replacement. Ansible is great for declarative, repeatable provisioning; Cockpit is a per-host web UI. remote-agents gives you interactive and autonomous access to shell, files, git, and cron across your whole homelab through one AI conversation, with end-to-end encryption. It shines for ad-hoc operations, mixed x86/ARM fleets, and "just go do this across everything" tasks.

Do I need a cloud account to manage my home servers with AI?

No. You can use the hosted Cloudflare relay, or run the self-hosted Rust relay (remote-agents-relay --bind 0.0.0.0:8080) on a box you already own — the NAS is a natural home for it — and point every agent at ws://your-host:8080. The entire control plane then stays inside your LAN.

Will my Raspberry Pis and x86 boxes need different commands?

Often, yes — and that's handled for you. Use target="os:linux" or tags like target="pi" to address groups, and write commands that adapt per host (try apt then dnf, try vcgencmd then sensors). Each host runs the branch that fits its architecture, and results come back per-host so you can see exactly what each machine did.

What happens to my scheduled backups if the internet goes down?

They still run. schedule_add installs a 6-field cron job that lives on the host itself, so it fires on time even if the relay link drops, your AI client is closed, or your WAN is out. The relay is only needed when you want to issue or inspect commands live.

Is it safe to give an AI shell access to my homelab?

Start every host in plan mode (read-only). The hard deny-list on critical paths like /etc/shadow and /boot is enforced even in bypass mode, all payloads are end-to-end encrypted, and the relay forwards them blind. You promote a host to edit or bypass only for the specific window you need it, then drop it back.

Wrapping up

That's homelab fleet management without the tab-juggling: one AI chat patches every Linux host with a single fleet_exec, schedules NAS backups that survive an outage, sweeps disk and temperature across x86 and ARM in one readout, manages Docker on the media box, and keeps the dangerous stuff behind plan mode, end-to-end encryption, and an unbreakable deny-list. Five machines, zero manual SSH sessions, and a homelab that finally behaves like one computer you can talk to.

Install: npm i -g remote-agents →
package on npm ·
source & docs on GitHub

Automate Database Backups Across a Server Fleet with AI: 7 Recipes for 2026

Alex Kernel — Thu, 18 Jun 2026 14:13:35 +0000

If you are still SSH-ing into four boxes to confirm last night's dump actually
ran, automated database backups across servers are exactly the kind of chore
that should be running on autopilot — not eating your evenings. In this guide we
wire up postgres backup automation for a small fleet (one primary, two
streaming replicas, an offsite backup box) and drive the whole thing from a
single AI interface using the MCP server
remote-agents. No agent
controller, no central scheduler to babysit — every host runs its own cron and
reports back per-host.

In short: every database host runs a lightweight agent connected to an
encrypted relay room. Your AI assistant (Claude or opencode) sees the whole
fleet as one machine and calls tools like schedule_add, fleet_exec,
file_stat, fleet_git, send_file, and set_mode. Cron jobs live on the
host, so a nightly pg_dump keeps running even if the relay link drops.
Payloads are end-to-end encrypted (AES-GCM-256) — the relay forwards
ciphertext blind.

Architecture: four hosts, one room
Installing agents and tagging db hosts
Quick summary of the seven recipes
Why and when to use this
Recipe 1 — Tag db hosts and look around in plan mode
Recipe 2 — Schedule a nightly pg_dump with retention
Recipe 3 — Verify backups are fresh across the fleet
Recipe 4 — Run a schema migration across replicas safely
Recipe 5 — Replication-lag and health checks
Recipe 6 — Read a prod .env read-only
Recipe 7 — Ship a dump host→host, SHA-256 verified
FAQ
Wrapping up

Architecture: four hosts, one room

Let's take a realistic small-SaaS database tier: a Postgres primary, two
streaming replicas for read scaling and failover, and an offsite box that only
stores compressed dumps. We'll also nod to a Windows SQL Server host at the end
to show the cross-platform story.

Host	Role	Tag	Stack
`db-primary`	Postgres primary (writes)	`db,primary`	PostgreSQL 16, Linux
`db-replica-1`	Streaming replica	`db,replica`	PostgreSQL 16, Linux
`db-replica-2`	Streaming replica	`db,replica`	PostgreSQL 16, Linux
`backup-box`	Offsite dump target	`backup`	rsync, gzip, Linux
`sql-win`	SQL Server (optional)	`db,windows`	SQL Server 2022, Windows

All agents join one relay room (say dbfleet). Tags let you address a group
in a single call: target="db,replica" hits both replicas, target="os:linux"
hits every Linux box, and target="all" sweeps the whole fleet. Note that
multi-tag targets match a host carrying either tag, so db,primary resolves
to every database host.

            ┌────────────── AI (Claude / opencode) ──────────────┐
            │            remote-agents (MCP, stdio)               │
            └───────────────────────┬────────────────────────────┘
                                    │ wss:// (E2E-encrypted)
                            ┌───────┴────────┐  relay (CF Worker or self-hosted)
                            │   room=dbfleet  │
        ┌───────────┬───────┴────┬────────────┬─────────────┐
   db-primary   db-replica-1  db-replica-2  backup-box   sql-win
  (db,primary)  (db,replica)  (db,replica)  (backup)    (db,windows)

The relay is interchangeable: use the hosted Cloudflare Worker, or run your own
Rust relay with remote-agents-relay --bind 0.0.0.0:8080 and point agents at
ws://your-host:8080. Either way the relay only ever sees encrypted frames.

Installing agents and tagging db hosts

On each host you install the package once and start the agent with the right
tags. For 24/7 database servers you'll want the background service form so the
agent survives reboots:

# once on every machine
npm i -g remote-agents

# the Postgres primary
remote-agents run --relay wss://<relay> --room dbfleet --token <secret> \
  --name db-primary --tags db,primary

# the two replicas
remote-agents run ... --name db-replica-1 --tags db,replica
remote-agents run ... --name db-replica-2 --tags db,replica

# the offsite backup target
remote-agents run ... --name backup-box --tags backup

# install as a systemd service for 24/7 hosts (instead of `run`)
remote-agents install --relay wss://<relay> --room dbfleet --token <secret> \
  --name db-primary --tags db,primary

Then confirm the whole fleet is online. Ask your AI:

"List the agents in the room."

Under the hood that calls list_agents, which returns each peer's OS family,
distro, kernel, shell, tags, and an update_available flag when a newer agent
version is out. It's a flat peer network — there is no controller node; every
host both executes and dispatches.

Also read: Run a security audit across your whole fleet

Quick summary of the seven recipes

# Recipe	What it does
1. Plan-mode look	Tag db hosts, set them to read-only `plan`, and inspect Postgres safely before touching anything.
2. Nightly pg_dump	`schedule_add` a `0 3 * * * *` host-local cron that dumps + gzips and prunes anything older than 14 days.
3. Verify freshness	`fleet_exec` + `file_stat` to confirm the dump exists, its size, and its mtime on every host at once.
4. Replica migration	`fleet_git` pull migrations + `fleet_exec` across `db,replica` with per-host results so a failed node is obvious.
5. Lag / health check	`fleet_exec target="db,replica"` running `pg_stat_replication` to catch lag and broken streaming.
6. Read prod config	`read_file` a production `.env` in `plan` mode — zero write risk.
7. Ship a dump	`send_file` a dump from primary to `backup-box` over a direct UDP channel, SHA-256 verified.

Why and when to use this

Database fleets are where "I'll just SSH in real quick" goes to die. A single
forgotten retention prune fills a disk; a silent pg_dump failure isn't noticed
until the day you need the dump; a schema migration applied to the primary but
not the replicas causes mysterious read errors hours later. Here's where driving
the fleet through one AI interface pays off:

Cron that survives the network. schedule_add installs the cron on the host itself, so your nightly 0 3 * * * * dump runs even if the relay link is down, your laptop is closed, or the AI session has long ended. The schedule is not tied to your connection.
Per-host truth in one call. fleet_exec and file_stat give you the dump size and mtime on all four boxes in a single round trip instead of four SSH sessions. One failing host does not sink the batch — it just shows up red in the aggregated result.
Replica maintenance without drift. fleet_git + fleet_exec against the db,replica tag apply the same migration to both replicas and report each one separately, so a half-applied change is impossible to miss.
Safe-by-default reads. plan mode makes a host read-only, so you can pull a prod .env or run pg_stat_replication during an incident with no chance of fat-fingering a write.
Cross-platform reach. target="os:linux" hits the Postgres boxes; a Windows SQL Server host joins the same room and answers os:windows targeting with a sqlcmd backup instead of pg_dump.

This is not a replacement for a declarative backup orchestrator or a managed
RDS-style service. It shines for self-hosted databases, small-to-mid fleets,
dev/staging tiers, and the operational glue around backups that nobody wants to
maintain in YAML.

Recipe 1 — Tag db hosts and look around in plan mode

Before automating anything, look first and touch nothing. Set every database
host to plan mode — read-only read_file, git_status, and safe exec
only — and get oriented.

Flip the database hosts to read-only.
Confirm Postgres is up and check current data directory size.
Eyeball where existing backups (if any) land.

set_mode    target="db,replica"   mode=plan
set_mode    agent_id=db-primary   mode=plan

fleet_exec  target="db,primary"   command="systemctl is-active postgresql && psql -tAc 'SELECT version();'"
fleet_exec  target="db,primary"   command="du -sh /var/lib/postgresql/16/main; df -h /var"
list_dir    agent_id=backup-box   path=/srv/backups

Tip: plan mode still allows a read-only exec, so psql -tAc 'SELECT ...'
and du -sh work fine. The moment a command would write, the agent rejects it.
Start every incident here — you literally cannot break prod from plan.

The aggregated reply comes back per host: you'll see db-primary reporting
active and a 240 GB data directory, while a replica that's catching up might
report differently. That per-host shape is the whole point — no guessing which
box you're looking at.

Recipe 2 — Schedule a nightly pg_dump with retention

This is the core of scheduled pg_dump automation. We install a host-local
cron on db-primary that dumps the database, gzips it, and prunes anything
older than 14 days. Because schedule_add writes the cron to the host, it
keeps firing at 03:00 every night whether or not anyone is connected.

Remember the cron is a 6-field spec — sec min hour day month dow — so
"3 AM nightly" is 0 0 3 * * *.

Switch the primary to edit so the agent may create the dump file and the wrapper script.
Add the nightly dump-and-prune schedule.
List schedules to confirm it registered.

# the command the cron runs on db-primary (one line, gzip + 14-day prune)
pg_dump -Fc -U postgres app_prod \
  | gzip > /srv/backups/app_prod-$(date +\%F).sql.gz \
  && find /srv/backups -name 'app_prod-*.sql.gz' -mtime +14 -delete

set_mode      agent_id=db-primary  mode=edit

schedule_add  agent_id=db-primary  name=nightly-pgdump \
  cron="0 0 3 * * *" \
  command="pg_dump -Fc -U postgres app_prod | gzip > /srv/backups/app_prod-$(date +%F).sql.gz && find /srv/backups -name 'app_prod-*.sql.gz' -mtime +14 -delete"

schedule_list agent_id=db-primary

The -Fc custom format gives you a compressed, pg_restore-friendly archive; a
240 GB cluster typically lands around a 30–45 GB gzipped dump depending on how
much of it is indexes and TOAST. The -mtime +14 -delete clause keeps roughly
two weeks of dumps and nothing more, so the disk doesn't quietly fill.

Note: for a mysqldump cron the only thing that changes is the command —
mysqldump --single-transaction app_prod | gzip > ... — wrapped in the exact
same schedule_add. And for the Windows SQL Server host you'd schedule a
sqlcmd -Q "BACKUP DATABASE ..." instead. The scheduler, retention, and
verification flow are identical across all of them.

To remove the schedule later (say you've migrated to WAL archiving):

schedule_remove  agent_id=db-primary  name=nightly-pgdump

Recipe 3 — Verify backups are fresh across the fleet

A backup you never check is a backup you don't have. This recipe answers the only
question that matters at 9 AM: did last night's dump actually run, and is it the
right size, on every host? We combine fleet_exec to find the newest dump with
file_stat to read its exact size and mtime.

Find the newest dump file on each db host.
file_stat that file for an authoritative size and modification time.
Flag anything older than ~26 hours as stale.

fleet_exec  target="db,primary"  \
  command="ls -t /srv/backups/app_prod-*.sql.gz 2>/dev/null | head -n1"

file_stat   agent_id=db-primary  path=/srv/backups/app_prod-2026-06-18.sql.gz

fleet_exec  target="db,primary"  \
  command="find /srv/backups -name 'app_prod-*.sql.gz' -mmin -1560 -printf '%p %s bytes\n' || echo NO_FRESH_BACKUP"

file_stat returns the size and mtime directly, which is more trustworthy than
parsing ls output. The -mmin -1560 window (26 hours) gives the 03:00 job some
slack — anything that didn't write a fresh file in that window prints
NO_FRESH_BACKUP, and because results are aggregated per host, a replica
that skipped its dump stands out instantly while the healthy boxes report a clean
~42 GB file.

Important: size is your early-warning signal. A dump that suddenly drops
from 42 GB to 200 KB almost always means pg_dump errored out mid-run (bad
credentials, a dropped connection, a full disk) and gzipped only the error.
Watching size over time catches silent failures that a green exit code hides.

You can fold this into a once-a-day self-check by wrapping the find in another
schedule_add that appends to a log — same host-local cron pattern as Recipe 2.

Also read: Build a cross-platform CI test farm

Recipe 4 — Run a schema migration across replicas safely

Replicas in database fleet management drift the moment a migration lands on
one box but not another. With fleet_git to pull the migration repo and
fleet_exec to apply it across the db,replica tag, both replicas move in
lockstep and you get a per-host verdict.

On true streaming replicas you don't run DDL directly (they're read-only and
replay WAL from the primary). This recipe fits the common real-world setup where
"replica" hosts also run migration tooling against a logical target, or where you
roll out an out-of-band maintenance script. Adjust to your topology.

Pull the latest migrations on both replicas at once.
Apply them, capturing per-host success/failure.
Re-check that both ended on the same schema version.

fleet_git   target="db,replica"  op=pull  repo=/srv/migrations  remote=origin  branch=main

fleet_exec  target="db,replica"  \
  command="cd /srv/migrations && ./run_migrations.sh 2>&1 | tail -n 5 || echo MIGRATION_FAILED"

fleet_exec  target="db,replica"  \
  command="psql -tAc 'SELECT max(version) FROM schema_migrations;'"

The payoff is the per-host aggregation: if db-replica-2 returns
MIGRATION_FAILED while db-replica-1 reports the new version, you know exactly
which node to fix — no scrolling through interleaved SSH output trying to figure
out whose error you're reading. One failing replica does not block the batch from
finishing on the healthy one.

Tip: put the hosts in edit mode (not bypass) for migrations. In edit,
the agent auto-creates a backup before any overwrite, so a botched
write_file to a config or script leaves you the original. Drop back to plan
the moment you're done.

Recipe 5 — Replication-lag and health checks

The single most useful replica maintenance check is replication lag: how far
behind the primary each replica is. From the primary you query
pg_stat_replication; from each replica you check pg_last_wal_replay_lag.
Both are one fleet_exec away.

From the primary, list connected replicas and their byte lag.
From each replica, read its replay delay.
Alert on anything beyond your threshold.

fleet_exec  target="db,primary"  \
  command="psql -xtAc \"SELECT client_addr, state, pg_wal_lsn_diff(sent_lsn, replay_lsn) AS lag_bytes FROM pg_stat_replication;\""

fleet_exec  target="db,replica"  \
  command="psql -tAc 'SELECT now() - pg_last_xact_replay_timestamp() AS replay_lag;'"

fleet_exec  target="db,replica"  \
  command="psql -tAc 'SELECT CASE WHEN pg_is_in_recovery() THEN 1 ELSE 0 END;' | grep -q 1 && echo OK_RECOVERY || echo NOT_A_REPLICA"

Run from plan mode — these are all read-only queries, so there's zero risk even
on a busy primary. The first query, sent to db-primary, shows you both replicas
as rows with their state (streaming is what you want) and lag_bytes. The
second, fanned out across the db,replica tag, returns each replica's replay lag
side by side. A replica that has fallen out of streaming shows up either as a
missing row in the primary's view or a ballooning replay_lag.

Note: a healthy LAN replica usually sits under a few hundred milliseconds
of replay lag. A sudden jump to tens of seconds (or a replica vanishing from
pg_stat_replication entirely) means streaming broke — often a WAL retention
or network issue. Catching it here, across both replicas in one call, beats
discovering it when a read query returns stale data.

Recipe 6 — Read a prod .env read-only

Sometimes you just need to confirm a connection string or a backup target path
without any chance of editing it. With the host in plan mode, read_file
hands you the file contents and nothing about the session can write.

Ensure the host is in plan mode.
read_file the config.
Optionally grep for one key with a read-only exec.

set_mode   agent_id=db-primary  mode=plan

read_file  agent_id=db-primary  path=/srv/app/.env

exec       agent_id=db-primary  command="grep -E '^(PGHOST|PGDATABASE|BACKUP_DIR)=' /srv/app/.env"

Because the agent is read-only, even if you (or the AI) followed up with a
write_file, it would be rejected. On top of that, a hard deny-list —
covering paths like /etc/shadow and /boot — applies on every host in
every mode, including bypass, so the truly sensitive system files are never
readable or writable through the agent regardless of how you set things up.

Important: plan mode is the right default for production database hosts.
Keep them in plan day to day and only flip a single host to edit for the
specific window you're changing something — then flip it straight back. It
turns "I'll be careful" into "I literally can't write right now."

Recipe 7 — Ship a dump host→host, SHA-256 verified

Finally, get the dump off the primary and onto the offsite backup-box.
send_file streams a file host→host over a direct UDP data channel (opened on
demand, with automatic relay fallback) and verifies it end-to-end with a
SHA-256 checksum. Because the receiving side performs a write, the
destination host needs edit or bypass.

Put backup-box in edit so it can write the incoming file.
send_file the latest dump from db-primary to backup-box.
Confirm arrival and size with file_stat on the receiver.

set_mode     agent_id=backup-box  mode=edit

send_file    agent_id=db-primary  \
  path=/srv/backups/app_prod-2026-06-18.sql.gz \
  to=backup-box \
  dest=/srv/offsite/app_prod-2026-06-18.sql.gz

file_stat    agent_id=backup-box  path=/srv/offsite/app_prod-2026-06-18.sql.gz

The transfer goes peer-to-peer where the network allows, so a 42 GB dump doesn't
have to round-trip through the relay — and if a direct UDP path can't be
established, it transparently falls back to the relay so the copy still
completes. The SHA-256 check means you find out about a corrupted transfer
immediately, not when a restore fails three weeks later. If you'd rather pull
from the receiving side, transfer_get is the mirror-image tool.

Tip: in the browser fleet-chat panel there's a Files view that does the same
move with a live progress bar, plus a binary-safe chunked download of any file
through the relay. Handy when you want to eyeball a dump's size or grab one to
your laptop without dropping to the CLI.

Set backup-box back to plan when the copy is done, so the offsite store is
read-only at rest:

set_mode  agent_id=backup-box  mode=plan

FAQ

How is this different from a cron job I'd write myself?

It's the same idea, but the cron is installed and managed through one AI
interface across the whole fleet, and schedule_add registers it on the host
so it survives relay outages and reboots. The difference is operational: you add,
list, verify, and remove backup schedules on four boxes from one place, and you
get per-host confirmation that each dump actually ran, instead of trusting four
independent crontabs you never look at.

Will my nightly pg_dump still run if the relay or my laptop is offline?

Yes. schedule_add writes a host-local cron that lives entirely on the database
server. The relay link and your AI session are only needed to create, list, or
remove the schedule — not to run it. Your 0 0 3 * * * dump fires at 03:00
regardless of whether anything is connected.

Is it safe to point this at a production database?

Start every host in plan mode, which is read-only — you can run
pg_stat_replication, read_file a .env, and check dump freshness with zero
write risk. Flip a single host to edit only for the specific change you're
making (edit auto-backs-up before overwriting), and a hard deny-list on paths
like /etc/shadow and /boot applies even in bypass. All command payloads and
results are end-to-end encrypted; the relay forwards ciphertext and never sees
your data or keys.

Can I back up MySQL or SQL Server the same way?

Yes — the workflow is database-agnostic. Swap the command inside schedule_add:
mysqldump --single-transaction ... | gzip for MySQL, or
sqlcmd -Q "BACKUP DATABASE ..." on a Windows host targeted via os:windows.
The scheduling, 14-day retention prune, freshness verification, and SHA-256
transfer all stay identical.

How do I keep the agents themselves up to date across the fleet?

Run fleet_update_check, which tells you which idle hosts have a newer agent
version available, then run npm i -g remote-agents@latest on those hosts. It
won't interrupt a host mid-task, so you can update the fleet without disrupting a
running backup or migration.

Wrapping up

One MCP interface, five hosts, zero manual SSH sessions: a nightly scheduled
pg_dump with 14-day retention runs host-local on the primary, freshness is
verified across the fleet with file_stat, replicas get migrations and lag checks
in lockstep, prod config is read safely in plan mode, and the dump lands offsite
with a SHA-256 guarantee. That's what automated database backups across servers
should feel like in 2026 — boring, observable, and running whether you're watching
or not. Add cross-platform targeting and the same recipes cover your MySQL and SQL
Server hosts too.

Install: npm i -g remote-agents →
package on npm ·
source and docs

Add authentication to your Nuxt 3 and Vue 3 applications (Logto)

Alex Kernel — Mon, 22 Dec 2025 11:45:51 +0000

Logto provides official SDKs for multiple frameworks, but the integration approach depends on your app type:

SSR / full-stack frameworks (Nuxt, Next.js, etc.) typically need a server-aware SDK that can safely store secrets and manage redirect-based flows on the server.
SPA frameworks (Vue, React, etc.) typically use a client-side SDK and rely on redirect-based login without server secrets.

In this guide, you’ll implement Logto authentication twice:
1) Nuxt 3 (SSR) using @logto/nuxt

2) Vue 3 (SPA) using Logto’s Vue SDK

No fluff — just a production-ready, copy-paste-friendly walkthrough.

Before you start: create a Logto app in the Console

In Logto Console, create an application that matches your framework:

For Nuxt 3, create a Traditional Web application.
For Vue 3, create a Single Page Application (SPA) application.

You’ll need these values for both setups:

Endpoint (your https://logto.io/ tenant URL)
App ID
(Nuxt only) App Secret

Part 1 — Nuxt 3 (SSR): add authentication with `@logto/nuxt`

Nuxt is often deployed with SSR (or hybrid rendering). Logto’s Nuxt SDK is designed for SSR and uses secure cookies + server-side handling to complete authentication.

1) Install the Nuxt SDK

npm i @logto/nuxt
# or
pnpm add @logto/nuxt
# or
yarn add @logto/nuxt

2) Add environment variables

Create a .env file:

NUXT_LOGTO_ENDPOINT="https://your-tenant.logto.app"
NUXT_LOGTO_APP_ID="your-app-id"
NUXT_LOGTO_APP_SECRET="your-app-secret"
NUXT_LOGTO_COOKIE_ENCRYPTION_KEY="a-strong-random-string"

Important: NUXT_LOGTO_COOKIE_ENCRYPTION_KEY must be a strong random string because it protects encrypted auth cookies.

3) Configure `nuxt.config.ts`

// nuxt.config.ts
export default defineNuxtConfig({
  modules: ['@logto/nuxt'],

  runtimeConfig: {
    logto: {
      endpoint: process.env.NUXT_LOGTO_ENDPOINT,
      appId: process.env.NUXT_LOGTO_APP_ID,
      appSecret: process.env.NUXT_LOGTO_APP_SECRET,
      cookieEncryptionKey: process.env.NUXT_LOGTO_COOKIE_ENCRYPTION_KEY,
    },
  },
})

4) Configure redirect URIs in Logto Console

Assuming your Nuxt app runs on http://localhost:3000:

Redirect URI: http://localhost:3000/callback
Post sign-out redirect URI: http://localhost:3000/

These must match the callback and return URLs used by the SDK.

5) Understand the built-in routes

The Nuxt module provides built-in routes for the auth flow:

/sign-in
/sign-out
/callback

You can customize them if you want:

// nuxt.config.ts
export default defineNuxtConfig({
  logto: {
    pathnames: {
      signIn: '/login',
      signOut: '/logout',
      callback: '/auth/callback',
    },
  },
})

If you change the callback path, update the redirect URI in Logto Console accordingly.

6) Implement a simple Sign in / Sign out button

<!-- pages/index.vue -->
<script setup lang="ts">
const user = useLogtoUser()
</script>

<template>
  <NuxtLink :to="`/sign-${user ? 'out' : 'in'}`">
    Sign {{ user ? 'out' : 'in' }}
  </NuxtLink>

  <pre v-if="user" style="margin-top: 16px">{{ user }}</pre>
</template>

useLogtoUser() is reactive — it updates when the session changes.

7) Request additional user claims (scopes)

By default, you get basic OIDC claims. If you need more (e.g., email/phone), add scopes:

// nuxt.config.ts
import { UserScope } from '@logto/nuxt'

export default defineNuxtConfig({
  logto: {
    scopes: [UserScope.Email, UserScope.Phone],
  },
})

8) Use the Logto client (server-only)

useLogtoClient() is server-only. On the client it returns undefined.

Example: fetch user info on the server once:

// composables/useServerUserInfo.ts
import { useLogtoClient, useState, callOnce } from '#imports'

export const useServerUserInfo = async () => {
  const client = useLogtoClient()
  const userInfo = useState<any>('logto-user-info', () => null)

  await callOnce(async () => {
    if (!client) return
    if (!(await client.isAuthenticated())) return

    userInfo.value = await client.fetchUserInfo()
  })

  return userInfo
}

Part 2 — Vue 3 (SPA): add authentication with the Vue SDK

Vue SPAs don’t have a server runtime to securely store secrets, so the recommended setup uses the Logto Vue SDK and SPA application settings in Logto Console.

1) Install the Vue SDK

Install Logto’s Vue SDK (Vue 3 only):

npm i @logto/vue
# or
pnpm add @logto/vue
# or
yarn add @logto/vue

2) Configure redirect URIs in Logto Console

Assuming your Vue app runs on http://localhost:5173:

Redirect URI: http://localhost:5173/callback
Post sign-out redirect URI: http://localhost:5173/

(Use your actual dev server origin if it’s different.)

3) Initialize Logto in `main.ts`

// src/main.ts
import { createApp } from 'vue'
import { createLogto } from '@logto/vue'
import App from './App.vue'
import router from './router'

const app = createApp(App)

app.use(
  createLogto({
    endpoint: import.meta.env.VITE_LOGTO_ENDPOINT,
    appId: import.meta.env.VITE_LOGTO_APP_ID,
  })
)

app.use(router)
app.mount('#app')

Add .env variables:

# .env
VITE_LOGTO_ENDPOINT="https://your-tenant.logto.app"
VITE_LOGTO_APP_ID="your-app-id"

4) Add a callback route

In SPAs, you must handle the redirect callback route.

Example with Vue Router:

// src/router/index.ts
import { createRouter, createWebHistory } from 'vue-router'
import Home from '../pages/Home.vue'
import Callback from '../pages/Callback.vue'

export default createRouter({
  history: createWebHistory(),
  routes: [
    { path: '/', component: Home },
    { path: '/callback', component: Callback },
  ],
})

Callback page:

<!-- src/pages/Callback.vue -->
<script setup lang="ts">
import { onMounted } from 'vue'
import { useLogto } from '@logto/vue'
import { useRouter } from 'vue-router'

const { handleSignInCallback } = useLogto()
const router = useRouter()

onMounted(async () => {
  await handleSignInCallback(window.location.href)
  router.replace('/')
})
</script>

<template>
  <p>Signing you in…</p>
</template>

5) Sign in / Sign out buttons

<!-- src/pages/Home.vue -->
<script setup lang="ts">
import { useLogto } from '@logto/vue'

const { isAuthenticated, signIn, signOut, getIdTokenClaims } = useLogto()

const handleSignIn = async () => {
  await signIn(import.meta.env.VITE_LOGTO_REDIRECT_URI)
}

const handleSignOut = async () => {
  await signOut(import.meta.env.VITE_LOGTO_POST_SIGN_OUT_REDIRECT_URI)
}
</script>

<template>
  <button v-if="!isAuthenticated" @click="handleSignIn">
    Sign in
  </button>

  <button v-else @click="handleSignOut">
    Sign out
  </button>
</template>

Add redirect-related env vars:

VITE_LOGTO_REDIRECT_URI="http://localhost:5173/callback"
VITE_LOGTO_POST_SIGN_OUT_REDIRECT_URI="http://localhost:5173/"

If you want to display the current user:

<script setup lang="ts">
import { ref } from 'vue'
import { useLogto } from '@logto/vue'

const { isAuthenticated, getIdTokenClaims } = useLogto()
const claims = ref<any>(null)

const loadClaims = async () => {
  claims.value = await getIdTokenClaims()
}
</script>

<template>
  <div v-if="isAuthenticated">
    <button @click="loadClaims">Load user claims</button>
    <pre v-if="claims">{{ claims }}</pre>
  </div>
</template>

Choosing between Nuxt and Vue integrations

If you are building a Nuxt app with SSR (or hybrid rendering), prefer @logto/nuxt because it’s designed for server-side flows and secure cookie handling.

If you are building a Vue SPA (no server runtime), use @logto/vue and the SPA application type in Logto Console.

Quick sanity check

Clicking Sign in should redirect you to Logto’s hosted sign-in screen.
After signing in, you should land on your callback route and end up back in the app.
Clicking Sign out should clear the shared session and return you to your post sign-out URL.

Final notes

This document intentionally keeps the examples minimal and production-oriented. Once authentication works, the next steps are typically:

Protecting routes (Nuxt middleware / Vue router guards)
Calling your APIs with access tokens
Adding organization/roles/permissions if your product needs it

Algolia Search in Nuxt 3: Production-Ready Integration Guide

Alex Kernel — Mon, 22 Dec 2025 10:33:23 +0000

Algolia is a hosted search engine designed for speed, relevance, and scalability. When combined with Nuxt 3, it allows you to build fast, SEO-friendly search experiences with minimal effort and full SSR support.

This guide walks through a practical, production-ready integration of Algolia in a Nuxt 3 application using the official @nuxtjs/algolia module. The focus is on real usage patterns, not abstractions.

Why Use Algolia with Nuxt 3

Nuxt 3 applications often require advanced search capabilities for blogs, documentation, dashboards, and e-commerce platforms. Algolia fits naturally into this ecosystem because it provides:

Extremely fast full-text search
Built-in typo tolerance and ranking
Seamless SSR compatibility
Auto-imported composables in Nuxt
Type-safe APIs with first-class TypeScript support

The official Nuxt Algolia module removes most of the boilerplate and exposes clean, composable APIs.

Requirements

Before starting, make sure you have:

A Nuxt 3 project
An Algolia account
At least one Algolia index with data
Algolia Application ID and Search API Key

Installing the Algolia Module

Install the official Nuxt module using the Nuxt CLI:

npx nuxi@latest module add algolia

Or with pnpm:

pnpm add @nuxtjs/algolia

The module will be registered automatically.

Environment Variables

Store Algolia credentials in environment variables.

ALGOLIA_APPLICATION_ID=YOUR_APP_ID
ALGOLIA_API_KEY=YOUR_SEARCH_API_KEY

Never commit API keys to version control.

Nuxt Configuration

Enable the module in nuxt.config.ts.

export default defineNuxtConfig({
  modules: ['@nuxtjs/algolia'],

  algolia: {
    // optional configuration
  }
})

The module automatically reads credentials from environment variables.

Basic Search Implementation

The most common way to query Algolia is via useAlgoliaSearch.

<script setup lang="ts">
const { result, search } = useAlgoliaSearch('products')

await search({ query: 'Laptop' })
</script>

<template>
  <ul>
    <li v-for="item in result.hits" :key="item.objectID">
      {{ item.name }}
    </li>
  </ul>
</template>

This performs a client-side search against the specified index.

Server-Side Search with SSR

For SEO-critical pages, use useAsyncAlgoliaSearch.

<script setup lang="ts">
const { data, pending } = await useAsyncAlgoliaSearch({
  indexName: 'products',
  query: 'Phone'
})
</script>

<template>
  <div v-if="pending">Loading…</div>
  <pre v-else>{{ data }}</pre>
</template>

This executes during server rendering and works seamlessly with Nuxt SSR.

Advanced Search Features

The module exposes additional composables:

useAlgoliaFacetedSearch for filters and facets
useAlgoliaInitIndex for index initialization
useAlgoliaRecommend for recommendations
useAlgoliaRef for direct client access

These cover most advanced search scenarios without manual client setup.

Edge and Cloudflare Support

When deploying to edge runtimes like Cloudflare Workers, enable fetch-based transport.

algolia: {
  useFetch: true
}

This ensures compatibility with restricted runtime environments.

Common Problems

No search results

Check index name
Verify index contains data
Confirm API key permissions

SSR errors

Use useAsyncAlgoliaSearch
Enable useFetch for edge runtimes

TypeScript issues

Update to the latest module version

Production Best Practices

Use SSR search only where SEO matters
Cache popular queries
Never expose Admin API keys
Index only searchable fields
Separate read and write operations

Final Notes

The official Algolia module for Nuxt 3 provides a clean and scalable way to add search to modern applications. With minimal configuration, you get fast search, SSR compatibility, and a composable API that fits naturally into the Nuxt ecosystem.

This setup is suitable for both small projects and large production systems and can be extended with InstantSearch or recommendation features when needed.

Digler — Open-Source Disk Forensics and File Recovery Tool

Alex Kernel — Sun, 21 Dec 2025 17:13:30 +0000

File Browser — Open-Source Web File Manager You Can Self-Host

Digler — Open-Source Disk Forensics and File Recovery Tool

Digler is an open-source disk forensics and file recovery utility designed for analyzing raw disks and disk images. It is written in Go, distributed as a CLI tool, and focuses on recovering deleted files and extracting forensic metadata.

Quick and Easy Installation

What Problem Does Digler Solve?

When files are deleted, the file system metadata may be lost, but the raw data often remains on disk. Digler helps by:

scanning raw disks or disk images
carving files without filesystem metadata
extracting forensic evidence
producing machine-readable forensic reports

This makes it useful for:

digital forensics
incident response
data recovery
security research
educational labs

SEO keywords covered:

disk forensics tool, file recovery CLI, digital forensics Go, raw disk analysis, DFXML

Key Features

🔍 Scan raw disks and disk images
🧩 File carving without filesystem metadata
📄 DFXML (Digital Forensics XML) report generation
🧱 Modular plugin-based architecture
⚡ Cross-platform (Linux, macOS, Windows)
🔓 Open-source

High-Level Architecture

Disk / Image
   ↓
Block Scanner
   ↓
Signature Detection
   ↓
File Carving Engine
   ↓
Recovered Files + DFXML Report

The plugin system allows Digler to recognize multiple file formats.

Tech Stack

Language: Go
Interface: CLI
Output: Files + DFXML XML
Architecture: Modular / plugin-based

Installation

Start Quickly with Easy Installation

Build from Source

git clone https://github.com/ostafen/digler.git
cd digler
make build

The compiled binary will be available in the bin/ directory.

Basic Usage

Scan a Disk Image

digler scan disk.img

Recover Files

digler recover disk.img --output recovered_files/

Generate Forensic Report

digler scan disk.img --dfxml report.xml

The DFXML file can be used in forensic pipelines and automated analysis.

Plugin System

Digler uses plugins to identify and recover file types.

Each plugin defines:

file signature
block structure
extraction logic

This allows easy extension for new formats.

Use Cases

Digital forensics investigations
Malware and incident response
Recovering accidentally deleted files
Security training and labs
Research on file systems

Safety Notes

Always work on disk images, not live disks
Use read-only access when possible
Ensure you have legal authorization to analyze data

Why Digler Is Worth Using

Digler is valuable because it:

focuses on raw forensic workflows
avoids unnecessary UI complexity
produces structured forensic output
is easy to extend and audit

It’s a solid open-source alternative for forensic tooling.

Final Thoughts

If you work with:

disk images
forensic analysis
data recovery
security tooling

Digler is worth exploring and learning from.

File Browser — Open-Source Web File Manager You Can Self-Host

Alex Kernel — Sun, 21 Dec 2025 17:09:14 +0000

File Browser — Open-Source Web File Manager You Can Self-Host

File Browser is a fast, lightweight, open-source web-based file manager that lets you manage files on a server through a clean browser UI.

It’s written in Go, distributed as a single binary, and designed to be:

easy to deploy
easy to secure
easy to self-host

GitHub repository:

https://github.com/gtsteffaniak/filebrowser

Why File Browser Is So Popular

File Browser solves a very practical problem:

“I want to manage files on my server without SSH, FTP, or heavy admin panels.”

Instead of complex setups, File Browser gives you:

a web UI
authentication
file operations
user permissions

All in one small binary.

SEO keywords naturally included:

open-source file manager, web file browser, self-hosted file manager, Go web application, server file management

Key Features

📁 Browse files and directories from your browser
⬆️ Upload / download files
✏️ Rename, move, copy, delete
👥 User and permission management
🔐 Authentication support
⚙️ Configurable root directory
🖥️ Runs as a single Go binary
🐧 Cross-platform (Linux, macOS, Windows)

High-Level Architecture

Browser UI
   ↓
HTTP API
   ↓
File system access
   ↓
Config / auth layer

There is no heavy database dependency by default, which keeps the system simple and fast.

Tech Stack

Language: Go
Frontend: Embedded web UI
Backend: Go HTTP server
Storage: Local filesystem
Deployment: Single binary

This makes File Browser ideal for:

VPS servers
NAS devices
homelabs
internal tools

Installation Guide

File Browser is extremely easy to install.

Option 1

Quick and Easy Installation

Option 2: Download Prebuilt Binary (Recommended)

Go to the releases page
Download the binary for your OS
Make it executable

Example (Linux / macOS):

chmod +x filebrowser
./filebrowser

Option 2: Install via Package Managers

Homebrew (macOS / Linux)

brew install filebrowser

Docker

docker run   -v /path/to/your/files:/srv   -p 8080:80   filebrowser/filebrowser

Option 3: Build from Source

git clone https://github.com/gtsteffaniak/filebrowser.git
cd filebrowser
go build

First Run & Login

On first launch, File Browser will:

create a configuration file
start a web server (default port: 80 or 8080)

Open in browser:

http://localhost:8080

Default credentials:

Username: admin
Password: admin

⚠️ Change credentials immediately after login.

Basic Configuration

Common flags:

filebrowser   --root /path/to/files   --address 0.0.0.0   --port 8080

This lets you control:

which directory is exposed
network interface
port

Use Cases

File Browser is widely used for:

managing files on VPS servers
NAS and home servers
DevOps workflows
temporary file sharing
internal admin panels

It’s especially useful when:

SSH access is limited
non-technical users need access
you want a lightweight solution

Security Notes

Always change default credentials
Use HTTPS (reverse proxy recommended)
Limit root directory access
Use firewall rules where possible

File Browser is simple, but security is still your responsibility.

Why This Project Is Worth Using

File Browser stands out because it:

does one thing very well
avoids unnecessary complexity
is easy to audit
is easy to deploy anywhere

If you like small, focused open-source tools, this is a must-have.

Final Thoughts

File Browser is a great example of:

pragmatic Go development
clean self-hosted tooling
real-world open-source utility

⭐ Star the repository if you use it or learn from it.

PearPass Desktop — Open-Source Peer-to-Peer Password Manager Built on Pear Runtime

Alex Kernel — Sun, 21 Dec 2025 17:04:16 +0000

PearPass Desktop — Open-Source Peer-to-Peer Password Manager Built on Pear Runtime

If you’re tired of “password managers” that still depend on centralized cloud servers, PearPass Desktop is a refreshing direction: a distributed password manager built on Pear Runtime, designed to keep your vault data on your devices and sync it across your own endpoints.

Download now

Why This Project Is Cool (and Why Devs Should Care)

PearPass Desktop is interesting for more than just end-user security:

Peer-to-peer / distributed sync mindset (no classic “one cloud to breach” architecture)
Open-source by default (easier to audit and extend)
Modern desktop stack (Pear Runtime + React ecosystem)
Great real-world reference for:
- crypto + security UX
- local-first apps
- end-to-end encryption product design
- multi-device sync without centralized infra

SEO keywords naturally covered:

open-source password manager, peer-to-peer password vault, local-first security app, end-to-end encrypted vault, Pear Runtime desktop app

Features (What You Get)

PearPass Desktop focuses on secure storage and usability:

Secure storage for passwords, identities, credit cards, notes, and custom fields
Cross-device and cross-platform synchronization
Offline access (local-first usage)
Encryption for vault security
Password strength analysis
Random password generator
Simple, clean UI

High-Level Architecture

PearPass Desktop follows a local-first model:

UI (React)
  ↓
Vault / state management
  ↓
Local encrypted storage
  ↓
Peer-to-peer distribution (Pear Runtime)

This means your “source of truth” is your devices, not a centralized web account.

Getting Started (Installation & Dev Setup)

This repo is primarily a developer setup flow (clone → install deps → run via Pear).

0) Requirements

Node.js (match the version in .nvmrc)
npm
Pear Runtime installed

Check Node version:

node --version

1) Clone the Repo

git clone https://github.com/tetherto/pearpass-app-desktop.git
cd pearpass-app-desktop

2) Update Submodules

PearPass uses submodules. Update them with the provided script:

npm run update-submodules

If you need a specific remote:

npm run update-submodules -- [remote-name]

3) Install Dependencies

npm install

4) Generate i18n (Translations)

PearPass uses Lingui. Generate and compile message catalogs:

npm run lingui:extract
npm run lingui:compile

5) Run the Desktop App (Dev Mode)

pear run --dev .

If everything is set correctly, the app should launch.

Testing

PearPass uses Jest for unit testing.

Run tests:

npm test

Usage: What to Try First

Once the app runs, a good “first session” checklist:

Create a vault and set a strong master password
Add sample entries:
- login
- note
- identity
Try password generator + strength checks
Explore sync / distribution options (if you have multiple devices)

Tech Stack

Pear Runtime
React
Styled Components
Redux
Lingui (i18n)
Jest (tests)

This is a great repo to learn how a security-focused desktop app structures:

state
encryption boundaries
UX flows for sensitive data

Who Should Fork This?

This repo is perfect if you want to build:

a local-first password manager fork
a secure “vault” module for another app
P2P sync experiments
privacy-first productivity tools

Ideas:

add hardware key / OS keychain integrations
add vault export formats
add threat-model docs + security tooling
build a plugin system for record types

Related Projects in the Ecosystem

PearPass also has:

browser extension
mobile app
vault core libraries

If you want full-stack parity (desktop + browser autofill), look at the extension repo too.

Final Notes

PearPass Desktop is one of those repos that’s both:

immediately useful
and a very teachable architecture for local-first security apps.

If you’re exploring modern, open-source security software — this is absolutely worth starring and reading.

BookHunter — Open-Source CLI Tool for Downloading and Managing eBooks

Alex Kernel — Sun, 21 Dec 2025 17:01:29 +0000

BookHunter — Open-Source CLI Tool for Downloading and Managing eBooks

BookHunter is an open-source command-line tool written in Go that allows users to download and manage eBooks from multiple online sources using a single unified CLI interface.

The project focuses on:

automation
multi-source support
cross-platform binaries
fast and simple CLI usage

GitHub repository:

https://github.com/bookstairs/bookhunter/

What Problem Does BookHunter Solve?

Downloading large collections of eBooks manually is time-consuming and repetitive.

BookHunter automates this process by providing:

a single CLI tool instead of multiple scripts
built-in parsers for different sources
multi-threaded downloads
consistent output formats

This makes it useful for:

personal libraries
research collections
automation workflows
CLI tool practice and learning

Key Features

📚 Download eBooks from multiple sources
⚡ Fast, multi-threaded downloads
🖥️ Cross-platform (Windows, macOS, Linux)
🧰 Simple and consistent CLI interface
📦 Supports common formats (PDF, EPUB, AZW3)
🔓 Open-source (MIT License)

SEO keywords covered naturally:

ebook downloader CLI, Go command line tool, open-source ebook downloader, automation with Go

Supported Sources

Depending on configuration and version, BookHunter supports:

SoBooks
TaleBook
Telegram channels
Other community-maintained sources

Each source is implemented as a separate command module.

High-Level Architecture

bookhunter (CLI)
├── source parsers
├── download manager
├── concurrency control
├── format handling
└── output directory management

The modular design makes it easy to extend with new sources.

Installation Guide

BookHunter provides prebuilt binaries for all major platforms.

macOS / Linux (Homebrew)

brew tap bookstairs/tap
brew install bookhunter

Windows (Scoop)

scoop bucket add bookstairs https://github.com/bookstairs/scoop-bucket
scoop install bookstairs/bookhunter

Manual Installation (All Platforms)

Open the GitHub releases page
Download the archive for your OS
Extract the binary
Move it to a directory in your PATH

Example (Linux / macOS):

chmod +x bookhunter
mv bookhunter /usr/local/bin/

Verify Installation

bookhunter --help

If installed correctly, you should see the available commands and options.

Basic Usage Examples

Download from SoBooks

bookhunter sobooks   --download ./ebooks   --thread 4

Download from Telegram Channel

bookhunter telegram   --appID YOUR_APP_ID   --appHash YOUR_APP_HASH   --channelID https://t.me/example_channel   --download ./tgbooks

You will need Telegram API credentials for this command.

Common Options

--download — output directory
--thread — number of concurrent downloads
--proxy — use HTTP/SOCKS proxy
--verbose — detailed logs

Use Cases

Building a personal digital library
Automating downloads in scripts
Learning Go by reading real-world CLI code
Teaching CLI tools and concurrency concepts
Research and offline reading workflows

Limitations and Notes

Availability of sources may change
Download speed depends on source limits
Users are responsible for complying with local laws and content licenses

BookHunter is a tool, not a content provider.

Why This Project Is Interesting

BookHunter is a good example of:

clean Go CLI design
modular architecture
real-world automation use cases
cross-platform distribution

It’s useful both as a tool and as a learning resource.

Final Notes

If you are interested in:

CLI tools
Go automation
managing large collections of files

BookHunter is worth checking out.

DiscovAI Search — Open‑Source AI Search Engine for Tools, Docs, and Custom Data

Alex Kernel — Sun, 21 Dec 2025 16:53:36 +0000

DiscovAI Search — Open‑Source AI Search Engine for Tools and Knowledge Bases

DiscovAI Search is an open‑source, AI‑powered search engine designed to index, understand, and search AI tools and custom knowledge bases using modern vector search + LLM reasoning.

The project combines:

semantic search (embeddings)
fast caching (Redis)
structured storage (Supabase / PostgreSQL)
modern frontend (Next.js)

It is suitable both as:

a production-ready AI search layer
an educational reference project for AI + web developers

GitHub repository:

https://github.com/DiscovAI/DiscovAI-search/

What Problem Does DiscovAI Search Solve?

Traditional keyword search fails when:

queries are vague or natural language
data is unstructured
users don’t know exact keywords

DiscovAI Search solves this by using semantic vector search, allowing users to search by meaning, not exact words.

Examples:

“tools for image generation”
“AI for document summarization”
“open-source alternatives to ChatGPT plugins”

Key Features

🔍 Semantic Search with Embeddings
🧠 LLM‑powered answer generation
⚡ Redis caching for fast responses
🗄️ Supabase (PostgreSQL + pgvector) backend
🌐 Next.js frontend
🔓 Fully open source

SEO keywords naturally covered:

AI search engine, vector search, semantic search, OpenAI embeddings, LLM search, Next.js AI app

High‑Level Architecture

User Query
   ↓
Next.js API Route
   ↓
Embedding (OpenAI)
   ↓
Vector Search (Supabase / pgvector)
   ↓
Redis Cache (optional)
   ↓
LLM‑generated response
   ↓
UI

This design keeps the system:

scalable
modular
easy to extend with new data sources

Tech Stack

Frontend: Next.js (React)
AI Models: OpenAI (embeddings + completion)
Database: Supabase (PostgreSQL + pgvector)
Cache: Redis
Language: TypeScript

Installation Guide (Local Setup)

Prerequisites

Node.js 18+
npm or yarn
OpenAI API key
Supabase account
Redis instance (local or cloud)

1. Clone the Repository

git clone https://github.com/DiscovAI/DiscovAI-search.git
cd DiscovAI-search

2. Install Dependencies

npm install
# or
yarn install

3. Environment Variables

Create a .env.local file:

OPENAI_API_KEY=your_openai_key

NEXT_PUBLIC_SUPABASE_URL=your_supabase_url
NEXT_PUBLIC_SUPABASE_ANON_KEY=your_supabase_anon_key

SUPABASE_SERVICE_ROLE_KEY=your_service_role_key

REDIS_URL=redis://localhost:6379

4. Supabase Setup

In Supabase:

Enable the pgvector extension
Create tables for:
- documents
- embeddings
Store vectors as vector columns

This enables fast semantic search.

5. Run the App

npm run dev

Open:

http://localhost:3000

You should now see the DiscovAI Search interface.

Indexing Data

DiscovAI Search can index:

AI tools
documentation
articles
internal knowledge bases

Typical flow:

Add documents to Supabase
Generate embeddings
Store vectors
Query via UI

Customization Ideas

Add your own datasets
Swap OpenAI for open‑source embedding models
Connect multiple vector indexes
Add authentication
Deploy to Vercel

Deployment

Recommended:

Frontend: Vercel
Database: Supabase
Cache: Upstash Redis

The project is cloud‑native and deploys cleanly.

Why This Project Is Useful

DiscovAI Search is valuable because it:

shows a real‑world AI search architecture
combines LLMs with vector databases correctly
is easy to fork and customize
works as both product and reference implementation

It’s a solid starting point for anyone building:

AI‑powered search
internal knowledge assistants
tool discovery platforms

Final Notes

This project demonstrates how modern AI search systems are built today, not in theory.

If you’re interested in:

semantic search
vector databases
LLM‑powered UX

DiscovAI Search is worth exploring.

Building a WoW Farming Bot with NitroGen

Alex Kernel — Sun, 21 Dec 2025 16:45:01 +0000

NitroGen is an open research project from the MineDojo / NVIDIA ecosystem.

It trains AI agents to play games purely from RGB screen pixels by imitating real human controller actions.

No game APIs.

No memory reading.

No engine hooks.

Just:

screen → neural network → controller input

In this guide, we extend NitroGen to build a vision-based farming bot for World of Warcraft (Retail, Classic, TBC, or private servers).

Important: This article is for research and educational purposes only.

Core Idea

Instead of scripting rotations or reading game memory, the agent learns by watching gameplay videos and copying human behavior.

The model:

sees health bars, enemies, minimap, cooldowns
predicts the next controller action
executes it like a human would

This makes the bot:

engine-agnostic
patch-resistant
closer to human behavior than classic bots

Key Features

Fully vision-based (no hooks, no addons)
Works with pretrained NitroGen models
Fine-tuning on your own WoW footage improves results
Human-like imperfection (non-deterministic loops)
Scales to multiple characters / accounts (research only)

What the Bot Can Do

With sufficient training data, the agent can learn:

Mob grinding
Herbalism / mining routes
Basic navigation paths
Simple combat rotations
Dungeon queue farming (LFD)

Performance depends entirely on dataset quality.

System Requirements

Windows 11 (for WoW process capture)
NVIDIA GPU (RTX 30/40 recommended, ≥8GB VRAM)
Python 3.12+
Xbox / PlayStation controller (or virtual controller via ViGEmBus)
World of Warcraft client installed
Screen resolution fixed during data collection

Installation

Fast Installation, No Extra Steps

1. Clone NitroGen

git clone https://github.com/MineDojo/NitroGen.git
cd NitroGen

2. Create Virtual Environment

python -m venv venv
venv\Scripts\activate

3. Install Dependencies

pip install -r requirements.txt

Make sure PyTorch detects your GPU:

python -c "import torch; print(torch.cuda.is_available())"

Preparing World of Warcraft

Recommended setup:

Windowed or borderless fullscreen
Fixed resolution (e.g. 1920x1080)
Controller-friendly UI layout
Consistent camera distance
Disable UI animations where possible

NitroGen works best with stable visual layouts.

Collecting Training Data

1. Record Gameplay

Record:

grinding sessions
gathering routes
combat encounters

At the same time, record:

controller inputs
button presses
joystick movements

This produces:

frame_t → action_t

pairs for training.

2. Dataset Structure

Example:

dataset/
├── frames/
│   ├── 000001.png
│   ├── 000002.png
│   └── ...
└── actions/
    ├── 000001.json
    ├── 000002.json
    └── ...

Training the Model

Fine-tune NitroGen on WoW footage:

python scripts/train.py \
  --config configs/wow_train.yaml \
  --dataset datasets/wow_grinding

Key parameters:

frame resolution
temporal window size
action discretization
batch size

Training is much more stable than reinforcement learning.

Running the Bot

python scripts/run_agent.py \
  --config configs/wow_eval.yaml \
  --checkpoint checkpoints/wow_finetuned.pt

The agent will:

read frames from the WoW window
predict controller actions
execute them in real time

Limitations

No long-term quest planning
Weak at PvP
Sensitive to UI changes
Requires significant training data
Not competitive with human players

This is a research agent, not a perfect farmer.

Detection and Ethics

NitroGen:

does not inject code
does not read memory
does not modify the client

However:

automation is still detectable on live servers
Blizzard actively bans bots

Use responsibly.

Why This Matters

World of Warcraft is one of the richest interactive environments ever built.

Using it as a benchmark helps research:

embodied AI
vision-based control
human-like decision making
long-horizon tasks

The techniques here apply far beyond games.

DEV Community: Alex Kernel

7 Ways to Run a Server Security Audit Across a Fleet in Minutes (2026)

Table of Contents

Architecture: ~20 hosts, one room

Installing agents and tagging the fleet

Why and when to run a fleet-wide audit

Quick summary table

Recipe 1 — Put the fleet in read-only plan mode

Recipe 2 — Find world-writable files and bad permissions

Recipe 3 — Audit SSH hardening across the fleet

Recipe 4 — Scan for leaked secrets and keys by content

Recipe 5 — Aggregate brute-force IPs with MapReduce

Recipe 6 — Check for pending security updates

FAQ

Is it really safe to run a security audit on production?

How many servers can I audit in one command?

How is this different from a dedicated scanner like OpenSCAP or Lynis?

Does the relay or any cloud service see my data?

Can I schedule the audit to run automatically?

Wrapping up

Homelab Fleet Management with AI: 7 remote-agents Recipes (2026)

Table of Contents

Architecture: five hosts, one room

Quick summary: the 6 recipes at a glance

Why manage a homelab fleet this way

Recipe 1 — Install agents and tag the homelab

Recipe 2 — One-command system updates across every Linux host

Recipe 3 — Nightly backups to the NAS that survive a relay outage

Recipe 4 — Whole-fleet health, disk, and temperature sweep

Recipe 5 — Docker management on the media host

Recipe 6 — Safe read-only inspection with plan mode and the denylist

FAQ

How is this different from Ansible or a dashboard like Cockpit?

Do I need a cloud account to manage my home servers with AI?

Will my Raspberry Pis and x86 boxes need different commands?

What happens to my scheduled backups if the internet goes down?

Is it safe to give an AI shell access to my homelab?

Wrapping up

Automate Database Backups Across a Server Fleet with AI: 7 Recipes for 2026

Table of Contents

Architecture: four hosts, one room

Installing agents and tagging db hosts

Quick summary of the seven recipes

Why and when to use this

Recipe 1 — Tag db hosts and look around in plan mode

Recipe 2 — Schedule a nightly pg_dump with retention

Recipe 3 — Verify backups are fresh across the fleet

Recipe 4 — Run a schema migration across replicas safely

Recipe 5 — Replication-lag and health checks

Recipe 6 — Read a prod .env read-only

Recipe 7 — Ship a dump host→host, SHA-256 verified

FAQ

How is this different from a cron job I'd write myself?

Will my nightly pg_dump still run if the relay or my laptop is offline?

Is it safe to point this at a production database?

Can I back up MySQL or SQL Server the same way?

How do I keep the agents themselves up to date across the fleet?

Wrapping up

Add authentication to your Nuxt 3 and Vue 3 applications (Logto)

Before you start: create a Logto app in the Console

Part 1 — Nuxt 3 (SSR): add authentication with @logto/nuxt

1) Install the Nuxt SDK

2) Add environment variables

3) Configure nuxt.config.ts

4) Configure redirect URIs in Logto Console

5) Understand the built-in routes

6) Implement a simple Sign in / Sign out button

7) Request additional user claims (scopes)

8) Use the Logto client (server-only)

Part 2 — Vue 3 (SPA): add authentication with the Vue SDK

1) Install the Vue SDK

2) Configure redirect URIs in Logto Console

3) Initialize Logto in main.ts

4) Add a callback route

5) Sign in / Sign out buttons

Choosing between Nuxt and Vue integrations

Quick sanity check

Final notes

Algolia Search in Nuxt 3: Production-Ready Integration Guide

Why Use Algolia with Nuxt 3

Recipe 1 — Put the fleet in read-only `plan` mode

Part 1 — Nuxt 3 (SSR): add authentication with `@logto/nuxt`

3) Configure `nuxt.config.ts`

3) Initialize Logto in `main.ts`