Skip to main content
Fly.io is the fully certified QM platform for Xerg’s current one-shot collection boundary. The adapter and snapshot format are host-independent; this page describes the Fly Managed Postgres transport.

​
Install the contained exporter

  1. Resolve the current public @xerg/cli version from npm and pin that exact version in the QM core image for contained export.
  2. Run xerg connect qm --print-views-sql locally and have QM’s Fly schema_admin apply the reviewed views and bounded-query indexes. Do not create or use Fly’s managed reader for Xerg.
  3. Store a backed-up 32-byte XERG_QM_IDENTITY_KEY in QM core’s Fly secrets.
  4. Set XERG_QM_TRUSTED_EXPORT=1 in QM core to enable the one-shot exporter deliberately.
The Slack sandbox receives no DATABASE_URL, identity key, Fly token, or Xerg credential by default. Even when the CLI is installed for offline snapshot audit, the skill forbids the sandbox from invoking live collection.

​
Provision a private Fly Sprite for offline Slack audit

QM’s current Fly Sprites backend resumes persistent Sprites and does not apply the configured sandbox OCI image to them. Pinning FLY_BASE_IMAGE therefore does not make xerg available inside an existing private Sprite. This does not affect the core exporter. If a QM Slack agent must audit an attached snapshot, an operator must explicitly approve and install the exact release into that administrator-owned private Sprite, then make its npm-global binary visible on the Sprite’s normal path:
Do not let the Slack agent perform this bootstrap implicitly. The private Sprite receives only the CLI and an authorized sanitized snapshot. It receives no live database/Fly authority, identity key, or Xerg credential by default. If a future QM sandbox backend actually consumes an OCI image, pinning the exact CLI in that image is still acceptable after verifying it inside the runtime.

​
Collect from the operator machine

Fly mode uses the operator’s existing local fly authentication. Xerg spawns Fly without a local shell and invokes a hidden, version-matched exporter in QM core. Fly credentials remain on the operator’s machine. QM’s existing DATABASE_URL remains inside core and is accepted only by that hidden command. The exporter validates its Fly environment, explicit opt-in, views, fingerprint, indexes, and identity continuity. It starts a read-only repeatable-read transaction, runs fixed bounded queries, HMACs identifiers before streaming, and exits. It has no listening service. Every resulting manifest discloses:
This is a process-containment boundary, not a view-only database credential. Doctor may report the core database role’s broad privileges as warnings without disguising them as least privilege. The local CLI rejects an exporter version mismatch, validates the digest/trailer and limits, redacts errors, and atomically publishes only an owner-readable artifact.

​
Current Slack boundary

A QM Slack agent may explain this setup, audit an authorized sanitized snapshot already available in its administrator-only private scope with an operator-provisioned exact CLI, interpret the local report, or read an already-pushed summary. It cannot bootstrap the CLI without approval, initiate Fly SSH or live database collection, or request infrastructure secrets. Continuous follow capture, durable tool-history capture beyond QM’s retention window, and live Slack-triggered collection are not currently supported.