Operations Capabilities — Xferity MFT Operational Control Features

Operations Capabilities

This page is the explicit, structured reference for Xferity’s operational capabilities.

CLI operations

The xferity CLI is the primary operator tool. It supports:

Validation and diagnostics

xferity validate — strict YAML validation; unknown fields fail at startup
xferity diag [flow] — pre-flight check of endpoints, keys, certificates, filesystem paths
xferity diag --dry-run — validate without any network connections

Execution

xferity run <flow> — run a flow once manually
xferity run <flow> --dry-run — simulate execution without transferring files
xferity run-all — run all configured flows
xferity run-service <flow> — long-running polling daemon mode
xferity run-service <flow> --interval-seconds N — run at fixed interval
xferity resume <flow> — resume from last committed state
xferity resume — resume all flows with incomplete state

Observability

xferity logs <flow> — tail flow logs with level filter
xferity flow status — current status summary for all flows
xferity flow history <flow> — per-run outcome history, retry counts, timestamps
xferity trace <filename> — full file lifecycle across all runs (queries audit log)

Web UI (Postgres-backed)

Xferity includes an authenticated Web UI available in Postgres-backed deployments:

Partner management — view, create, edit, test partner definitions
Certificate inventory — import, generate, view, bind to partner roles, expiry tracking
PGP Key inventory — import, view capabilities, bind to partner roles
Partner Crypto Policy — unified view of all crypto roles per partner
Security posture dashboard — Active Findings, Suppressed Findings, trend charts
Suppression management — acknowledge findings without erasing them from history
Flow status and history — per-flow run history, last outcome, retry counts
Local secrets vault — create and manage local-vault: secrets without plaintext exposure
AS2 inbox — inbound AS2 messages and MDN tracking
License status — current license, feature flags, activation state

HTTP REST API

Every Web UI page is backed by an authenticated HTTP REST API:

Partner CRUD and test endpoints
Certificate and PGP Key lifecycle endpoints
Flow run trigger: POST /api/flows/<flow>/run
Job queue inspection
Posture findings query
Suppression management
Audit query: GET /api/audit?file=<basename>
Health and metrics endpoints

Job queue and workers

Postgres-backed deployments add durable job execution:

Supported triggers enqueue durable Job records in PostgreSQL
Workers claim jobs using SELECT FOR UPDATE SKIP LOCKED — prevents duplicate execution
Jobs survive process restarts and crashes
Multiple workers can run against the same Postgres backend
Worker readiness exposed at /health/worker (unauthenticated)

Run history and state

For every flow execution, Xferity records:

run ID
start and end timestamps
outcome (success, partial, failure)
file count: processed, skipped, failed
retry count
error details where applicable

History is queryable via CLI (xferity flow history <flow>) and HTTP API.

Dead-letter inventory

Files that exhaust all retry attempts:

moved to configurable dead-letter directory
inventoried for operator review
can be manually retried or discarded
preserved from loss during recovery

Notification delivery

Operational events trigger notifications via:

Email — SMTP with configurable TLS, port, and from address
Slack — incoming webhook URL
HTTP Webhook — POST to any URL with configurable headers
Ntfy — topic URL (supports self-hosted ntfy)
Gotify — server URL with application token
Pushover — user key and application token

Events delivered:

flow success
flow failure
flow retry exhaustion
posture regression alerts

Notification routing is configurable globally and overrideable per flow or per partner.

Configuration operations

xferity validate — validates all YAML config files including partners and flows
Configuration under version control — every partner, flow, and setting is a reviewable file
Environment placeholder expansion (${VAR}, ${VAR:-default}) in config files
Strict parsing: unknown YAML fields cause startup failure — no silent drift

Deployment operations

Xferity supports the following deployment models:

Native binary — direct host installation, standard service management
Docker — multi-stage Dockerfile; Alpine-based runtime image
Docker Compose — includes Compose file with mounts for config, flows, state, logs, keys
Windows native — Windows-compatible binary for replacing Windows-based MFT or WinSCP jobs

Backend-dependent capability differences

Capability	File-backed	Postgres-backed
Local state and history	✓	✓
CLI execution	✓	✓
Auth and sessions	limited	full
Crypto inventory (UI)	limited	full
Suppressions	—	✓
Posture snapshots and trends	—	✓
Regression alerts	—	✓
Worker-driven durable jobs	limited	✓
AS2 message persistence	—	✓
Local AES-256 vault	—	✓

Capability summary

Xferity operations capabilities include:

Full CLI: validate, diag, run, run-service, resume, logs, flow-status, flow-history, trace
Web UI with partner, certificate, PGP key, posture, secrets, AS2, and license management
Authenticated REST API for all UI operations
Postgres-backed durable job queue with worker execution
Per-run history with outcome, retry counts, and file-level results
Dead-letter inventory for files that exhaust retries
6-channel notification delivery (Email, Slack, Webhook, Ntfy, Gotify, Pushover)
Strict YAML validation with startup failure on unknown fields
File-backed and Postgres-backed operation modes
Docker, Docker Compose, Linux binary, Windows binary deployment