What it is
Self-hosted managed file transfer
Run SFTP, FTPS, AS2, S3-compatible storage, WebDAV, and Azure Blob workflows in infrastructure you control.
Two deployment modes: file-backed automation or Postgres-backed operator platform
Self-hosted MFT architecture for controlled enterprise environments
Xferity supports two runtime models: file-backed execution for lean automation, and Postgres-backed execution for durable jobs, operator UI, API access, posture data, and crypto inventory.
Why it wins
Lean when you need lean. Rich when you need rich.
Start with file-backed automation for fast deployment, or run the full Postgres-backed operator platform when you need shared durable state, UI, API, and workers.
Who it is for
Infrastructure, security, and operations teams
Especially teams replacing transfer scripts, FTP estates, or heavyweight legacy MFT platforms without giving up control or auditability.
Flexible deployment packaging
- Run as a single Go binary with no container runtime required
- Deploy with Docker using the repository multi-stage Dockerfile
- Use Docker Compose when you want mounted config, flows, logs, storage, and PostgreSQL-backed operation
- Run natively on Windows when replacing WinSCP scripts, scheduled tasks, or Windows-based MFT software
- Run natively on Linux when you want direct control over service management and filesystem layout
Deployment targets
Docker Docker Compose Linux binary Windows binary Air-gapped deployment
Deploy the same product in the environment you already operate.
Product proof
See how Xferity looks in daily operations
From flow execution and run history to audit traceability, operator workflows, and security posture review, Xferity is built to make secure file transfer visible and manageable.
Choose the implementation that fits your environment
| Requirement | File-backed mode | Postgres-backed mode |
|---|---|---|
| Best fit | Lean secure flow automation with minimal dependencies | Full operator platform for broader production operations |
| Packaging options | Single native binary or Docker deployment | Single native binary or Docker deployment with PostgreSQL |
| State model | Local disk-backed state | Shared durable PostgreSQL-backed state |
| Execution model | Direct in-process flow execution | Queued jobs with worker-based execution |
| Operator surface | CLI-first | CLI + Web UI + REST API |
| Advanced features | Core transfer automation and auditability | Workers, posture snapshots, suppressions, local vault, crypto inventory, AS2 persistence |
| When to choose it | Fast setup, single-node execution, smaller self-hosted installations | Durable jobs, shared state, richer operating workflows, broader team access |
What operators actually do
How teams operate Xferity day to day
See how teams use Xferity to define endpoints, run flows, investigate failures, review security posture, and operate file transfer without script sprawl.
Define partners and protocols
Configure SFTP, FTPS, AS2, S3-compatible storage, WebDAV, and Azure Blob endpoints with explicit trust material and secret references.
Run versioned transfer flows
Use named YAML flows for upload and download workflows with scheduling, retry, idempotency, cleanup, and notification routing.
Monitor runs and investigate failures
Review flow status, run history, logs, retry outcomes, and file lifecycle traces instead of reconstructing incidents from script output.
Review security posture
In Postgres-backed deployments, monitor findings, suppressions, snapshots, and regression alerts across crypto, secrets, transport, auth, flow drift, and platform scope.
Manage crypto and trust inventory
Use certificate and PGP key inventory, partner crypto policy, and role bindings for AS2, FTPS, and OpenPGP workflows.
Choose the right operating model
Stay file-backed for lean automation or use Postgres-backed workers, UI, API, local vault, AS2 persistence, and shared durable state when operations mature.
Reference architecture diagram
Secure enterprise file exchange and transfer automation for on-prem and private cloud environments.
How it works
Review Xferity architecture, trust boundaries, and the ingest → decrypt → validate → route → deliver → notify flow with reliability controls.
Reliability controls
- Configurable retry with jitter and bounded backoff for transient failures
- SHA-256 content-hash idempotency across retries and reruns
- Distributed flow locking and stale-lock takeover to prevent duplicate execution
- Dead-letter handling and xferity resume for controlled recovery
Migration-focused proof
- Replace cron jobs and WinSCP-style scripts with named YAML flows under version control
- Keep protocol trust explicit instead of relying on hidden client settings or one-off scripts
- Move from local script logs to structured audit events, run history, and file traceability
- Adopt the smallest deployment that fits now: file-backed first, Postgres-backed when operator scale requires it
Replace scripts and legacy MFT with a cleaner operating model
| Problem | What teams live with now | What Xferity changes |
|---|---|---|
| Script sprawl | Transfer logic scattered across cron jobs, shell scripts, or scheduled clients | Named YAML flows with validation, scheduling, retry, idempotency, and recovery |
| Operator visibility | Logs live on individual hosts and are hard to reconstruct | Flow status, history, logs, metrics, and audit traceability are part of the operating model |
| Trust handling | Host keys, certificates, and credentials drift across machines | Partner trust and secrets are configured explicitly and reviewed in one place |
| Path to production | Every new workflow adds more custom maintenance | Start file-backed for speed, then move to Postgres-backed shared-state operations when needed |
Product questions buyers ask first
Which Xferity implementation should we start with?
Start with file-backed mode when you want minimal dependencies, local disk-backed state, and direct flow execution on a single node. Use Postgres-backed mode when you need durable queued jobs, worker-based execution, shared state across processes, Web UI, REST API, certificate and PGP key inventory, posture snapshots, AS2 persistence, and local encrypted vault secrets.
Can we start lean and move to the full platform later?
Yes. Start with file-backed mode for evaluation, smaller self-hosted deployments, and minimal dependencies. Move to Postgres-backed mode when you need shared durable state, broader operator workflows, and the full UI/API/worker platform.
What does Xferity replace in practice?
Xferity is designed to replace FTP endpoint sprawl, cron or WinSCP-style transfer scripts, and heavyweight legacy MFT estates with versioned flows, explicit protocol trust, audit-ready records, and customer-controlled deployment.
Which protocols does Xferity support today?
Xferity supports SFTP, FTPS, AS2, Amazon S3 and S3-compatible storage, WebDAV, and Azure Blob Storage. These protocols are not interchangeable. Each one has its own trust model, authentication pattern, and operational behavior.
What makes Xferity safer than transfer scripts?
The core difference is operational control. Xferity gives you named YAML flows, strict configuration validation, retry with bounded backoff, SHA-256 idempotency, flow locking, dead-letter handling, audit records, and file traceability. Script estates usually spread that logic across multiple hosts and make failures harder to investigate.
What do we get only in Postgres-backed mode?
Postgres-backed mode enables the broader operator platform: durable queued jobs, worker execution, authenticated sessions, Web UI, REST API, certificate and PGP key inventory, posture snapshots and suppressions, local encrypted vault secrets, and AS2 message and MDN persistence.
Does Xferity require SaaS or cloud control plane access?
No. Xferity is self-hosted and runs in customer-controlled infrastructure. File-backed mode can run without external services. Postgres-backed mode requires PostgreSQL, but not a vendor SaaS runtime. Air-gapped deployment is supported.
How do operators investigate transfer failures?
Operators use flow status, flow history, structured logs, diagnostics, audit trace, health endpoints, and Prometheus metrics. The operating model is built to answer what failed, when it failed, and what happened to a file without reconstructing events manually.
Is this a heavyweight legacy-style MFT stack?
No. Xferity is designed as a self-hosted platform that can run as a single Go binary or Docker deployment, with a lean file-backed option and a richer Postgres-backed option when you need broader operator workflows.
See the deployment mode that matches your environment
Book a technical walkthrough focused on file-backed automation, the Postgres-backed operator platform, migration from scripts or legacy MFT, and the controls your team actually needs.