How It Works — PeerAegis MFT

Step by step

From zero to transferring in under an hour.

Deploy the infra-server

The infra-server is a single Go binary — or a Docker Compose stack if you prefer. It handles station enrolment, session brokering, the built-in STUN/TURN relay, the admin web panel, and licence validation. One binary, one config file.

During the trial period, we host the infra-server for you. You skip this step entirely and receive your server address, admin credentials, and enrolment tokens by email.

Enrol your stations

Install the daemon — a Windows Service or Linux systemd unit — on each machine that will send or receive files. Generate a one-time enrolment token from the admin panel for each machine. Run peeraegis-daemon enrol --token <TOKEN> --server <SERVER_URL>.

The daemon generates an Ed25519 keypair on first run. During enrolment, it presents its public key to the infra-server authenticated by the token. The infra-server registers the station and issues it an identity. The private key never leaves the machine — not during enrolment, not ever.

Tokens expire in 24 hours and can only be used once. A partner you enrol with a token that is scoped to their IP range cannot use that token from a different network.

Configure transfer policy

In the admin panel, define relationships between station pairs: who can send to whom, in which direction. For each pair, set the crypto mode (none, sign, encrypt, or sign+encrypt), cipher (aes-256-gcm or chacha20-poly1305), and optionally file-type glob patterns and size limits.

Policy is stored server-side and injected into the WebRTC SDP offer at session time. The daemon applies the policy it receives — it has no mechanism to negotiate a weaker mode.

Drop a file in the outbox

The daemon polls its configured outbox directory every 15 seconds. When a new file appears, it contacts the infra-server to initiate a session with the target station. The infra-server exchanges SDP offers between the two daemons — IP candidates, ports, DTLS fingerprints — then steps back.

The two daemons negotiate a direct WebRTC DataChannel. In encrypt mode, a per-file ephemeral X25519 key is derived; the file is chunked into 32 KB blocks, each encrypted and streamed directly to the receiver. On completion, the file is moved to the sender's sent/ archive and appears in the receiver's inbox/.

If a direct peer connection cannot be established (strict NAT, firewall blocking UDP), the transfer automatically falls back to the TURN relay embedded in your infra-server. The connection type (DIRECT or RELAY) is recorded in the transfer log.

Review the audit log

Every completed transfer writes a structured log entry: timestamp, sender, receiver, filename, file size, SHA-256 hash, crypto mode, cipher, connection type, duration, and status. The log is searchable and filterable in the admin panel. Professional and Enterprise tiers can export to CSV or Excel.

Your audit team gets cryptographic evidence — not a self-reported log. The file hash is computed before encryption and recorded before the transfer begins, so a corrupted or tampered delivery produces a hash mismatch that shows in the log.

The technology

Why WebRTC DataChannels?

WebRTC was designed for real-time peer-to-peer communication between browsers. We use the same underlying primitives — DTLS, ICE, SCTP DataChannels — for file transfer between daemon processes.

NAT traversal built in

ICE (Interactive Connectivity Establishment) automatically finds the best path between two endpoints, even behind NATs and enterprise firewalls. No open inbound ports required on either side.

DTLS-encrypted transport

Every WebRTC DataChannel uses DTLS (Datagram TLS) for transport encryption. The relay server receives UDP datagrams it cannot decrypt — even before the application-layer encryption envelope is considered.

Ordered, reliable delivery

SCTP over DTLS provides ordered, reliable delivery of DataChannel messages. Files arrive in order, with retransmission on packet loss — no application-level reassembly logic needed.

Questions

Common technical questions.

What happens if the infra-server goes down mid-transfer?

Once the WebRTC peer connection is established, the infra-server plays no further role in the transfer. File bytes flow directly between the two daemons. An infra-server outage after session establishment does not interrupt an in-progress transfer. If the server is down when a new file appears in the outbox, the daemon retries on the next polling cycle.

Does the daemon need to be running continuously?

Yes — the daemon is designed to run as a persistent background service (Windows Service or Linux systemd unit). It polls the outbox every 15 seconds and receives incoming transfers in real time. If the daemon is stopped while a file is in the outbox, the file will be picked up and sent on next start.

How large can files be?

There is no file size limit imposed by PeerAegis. Files are streamed in 32 KB chunks — a 50 GB file is handled identically to a 50 KB file, just with more chunks. The limiting factor is available disk space at the receiver and the speed of the network path between the two stations.

Can I send to multiple receivers at once?

Yes. Each station can have multiple outbox/destination configurations. If a file needs to go to three receivers, place it in each of the three outbox directories configured for those destinations. The daemon handles concurrent transfers independently — each is a separate peer connection.

What operating systems does the daemon support?

The daemon ships as a Windows Service (Windows 10 / Server 2016+) and a Linux systemd unit (any systemd-based distro with a 4.14+ kernel — tested on RHEL 8/9, Ubuntu 20.04+, Debian 11+). Both platforms receive the same binary distribution and feature set.

Three components. One encrypted peer connection.