Deploying Xferity — Self-Hosted MFT on Docker, Linux, or Windows

Deployment

Xferity is a modern self-hosted managed file transfer (MFT) platform designed to run in infrastructure your team already operates.

Supported deployment options include:

native binary deployment
Docker deployment
Windows-native deployment
file-backed runtime
Postgres-backed runtime with workers

Your deployment choice affects state handling, worker behavior, UI and API access, and operational dependencies.

Deployment modes

File-backed runtime

Use file-backed mode when you want:

single-node execution
local disk-backed state
minimal dependencies
direct in-process flow execution

This is usually the simplest path for evaluation and for smaller self-hosted MFT installations.

Postgres-backed runtime with workers

Use Postgres-backed mode when you need:

durable queued jobs
worker-based job execution
authenticated user and session persistence
certificate and PGP Key inventory
AS2 message and MDN persistence
posture snapshots, suppressions, and regression alerts
local encrypted secret storage

In this mode, Postgres is part of the control-plane state model — it provides the shared durable state that the full operator feature set depends on.

Packaging options

Native binary

The application is built as a single Go binary. This is the most direct option when you want explicit control over service registration, filesystem layout, and host hardening. No container runtime is required.

Docker

The repository includes a multi-stage Dockerfile. It builds a Linux binary into an Alpine-based runtime image, creates a non-root user, prepares runtime directories under /app, and exposes port 8080.

The default entry point is run-service nav_incoming --interval-seconds 300 — suitable for examples. Production deployments should override this to match their flow names and scheduling design.

Docker Compose

The repository includes a Compose file that mounts config, flows, state, logs, keys, and storage, and publishes port 8080.

The service name is xferity:

docker compose up xferity

Windows-native deployment

Windows is a supported operating target. This is relevant for teams replacing scheduled Windows file transfer jobs or local filesystem-based automation. The run-service mode is especially relevant for simple polling workflows on Windows hosts.

Runtime layout

Most deployments need to plan these paths explicitly:

global configuration
flow definitions
partner definitions
state storage
audit files
logs
storage landing or staging directories
keys and certificates

These paths are part of the trust boundary. They affect permissions, backup scope, audit retention, and operator procedures.

Service-style execution

Xferity supports a long-running polling mode through:

xferity run-service <flow>

That mode can run:

at a fixed interval using --interval-seconds
on the flow’s schedule_cron

This is useful for inbound polling and repeated partner checks.

Database startup behavior

When state.backend=postgres, startup initializes the Postgres backend and applies migrations from the repository migration set. Database reachability, schema permissions, and migration success are therefore deployment requirements.

Security and exposure considerations

Deployment planning usually needs to answer:

where secrets and bootstrap credentials come from
where keys and certificates are mounted
who can read or write audit and state paths
whether the Web UI and API are internal-only or exposed through a reviewed ingress path
whether TLS is configured for the UI
how partner trust material is rotated

When hardened mode is enabled, some insecure settings are rejected at startup rather than accepted with warnings.

Monitoring and health checks

The deployment surface includes health and metrics endpoints, but their exposure is not uniform:

/health/worker is intended for unauthenticated readiness checks
/health, /health/secrets, and /health/certificates require authenticated access
/metrics requires authenticated admin access

That affects how you integrate Xferity with Prometheus or external monitors.

What deployment does not imply

Xferity does not implement:

clustering
HA coordination
a Kubernetes operator
distributed control-plane management

Documentation should not imply those features.