One folder. Every transfer verified.
PIGEON combines several ways of moving data with one rule: nothing is finished until the destination has been checked.
Ways to move data
| Mode | What it does | Best for |
|---|---|---|
| Direct copy | Multi-threaded copy with resume. An interrupted run picks up where it stopped instead of starting over. | Local disks, shares, removable media |
| Archive and go | Packs the source into one compressed stream, unpacks it at the destination, then hashes every file that landed. A single stream has no halfway point, so an interrupted run restarts rather than resuming. | Huge numbers of small files, slow links |
| Differential sync | Compares the source against what the destination already holds and sends only the files whose contents differ. Can mirror deletions too, off by default. | Repeat runs to the same destination |
| Offline batch | Packs only what changed into a batch file you sign with your own key, for hand-carrying across an air gap. | Disconnected systems that need regular updates |
Reaching the far end
A transfer can run entirely against paths the machine already has mounted. It can also cross a network — PIGEON either connects out, or waits for something to connect to it. Every network role is off until a profile or a command turns it on.
PIGEON connects out
- SFTP, through the host’s own OpenSSH client
- HTTPS, with mutual-TLS client certificates, through the host’s own curl
- FTPS with explicit TLS, through the same client
PIGEON bundles no protocol implementation of its own for any of these — it drives the tools the host already ships and trusts, so your hardened SSH configuration is the boundary, not a vendor’s black box. No credential is ever written to a profile or to disk: a profile holds a host, a path, and at most the path to an identity file. Plain unencrypted FTP is not implemented at all, in either direction. TFTP exists as a gated option for equipment that speaks nothing else — left out of builds by default, and refused at runtime even in a build that has it unless a separately signed authorisation is present.
PIGEON is the far end
serve-sftp— the host’s own OpenSSH server, public-key onlyserve-https— an embedded server, mutual TLS, client certificates you add by hand. A certificate you remove stays accepted until the server is restartedserve-watch— not a listener: it watches a drop directory and applies each batch that lands there, setting aside anything it refuses rather than deleting it
Both server roles run in the foreground while you watch them, and both are proven end to end on Linux; the embedded HTTPS server is proven as a Windows binary too. Standing up the SFTP server on Windows is implemented but not yet proven end to end, and the directory-confinement option it uses on Linux has no Windows equivalent — Windows’ own OpenSSH does not implement it. Differential sync and resume work over the remote transports; archive-and-go and the offline batch workflow deliberately do not, because both need something at the far end to act on what arrives.
Profiles for common jobs
A profile holds the settings for a kind of transfer: how it moves, how many threads, compression, bandwidth cap, and which files to include or skip. Eleven ship with the product, covering the shapes below. They are plain files: edit one, write your own, or share one with another site. A profile you write that carries a built-in’s name takes precedence over it, and deleting your file restores the original.
| The job | What the profile sets up |
|---|---|
| Deep, intricate trees of geospatial or environmental product data — a hundred thousand files and very long paths — over a long-haul, constrained link | Archive-and-go, compression, four threads, verification, resume, and exclusions for temporary and cache folders |
| An extremely narrow link, the kind measured in tens of kilobits | Differential batches, maximum compression, metadata stripping, a hard 55 KB/s cap, single-threaded |
| Very large sequential files — machine images, server backups — over a fast local network | Light compression, eight threads, full verification, resume |
| Enormous numbers of small files, such as an image or product library | Archive-and-go, light compression, six threads, and exclusions for the thumbnail and metadata files such libraries collect |
| Ordinary bulk movement inside a trusted network | Light compression, six threads, verification, resume |
| An older or more constrained destination that needs short, plain filenames | Archive-and-go, light compression, two threads, conservative name safety |
| A steady one-way flow across a diode, to a PIGEON receiver running unattended | Offline batches, differential, one-way, and replay chaining. Every batch is a complete snapshot; the receiver checks each one and refuses a replay |
| A single one-way delivery on removable media | The same one-way posture, plus a record of the volume the batch was written to. The far end sets aside anything the snapshot does not list |
| A relay you do not fully trust — a shared drop, a cloud folder, a courier you cannot vouch for | One-way batches with replay chaining and media identity, meant to be paired with the receiver’s public key so the batch is sealed to them |
| A transfer that has to survive a logoff or a power loss | Runs through the background service’s job queue: verified, resumable per file, retried with backoff until it lands |
| Everything protective on, running in front of you | Verification, resume, per-file byte-range resume, sparse-file aware, no background service. Deliberately no deletion and no move, so there is nothing set aside that it could mislead you about |
What’s included
Delivery and integrity
- SHA-256 receipt for every run, built from the files that landed — never from the copy of them that went past on the way
- Change detection by content hash. Not size, not timestamps, not the two together — so an edit that lands in the same second as the last run is still seen
- Resume after interruption in direct-copy mode
- Batches you sign with your own key; the far side verifies the signature, and can be set to refuse an unsigned batch
- Package self-check to confirm the folder is exactly what was issued
Operation
- Readiness check that reports every problem before a transfer starts
- Plain-language errors with stable codes and a note on whether the destination is usable
- Exit codes a script can act on
- Bandwidth cap shared across all worker threads, on a schedule if you want one. Archive-and-go is the exception: it does not throttle, and says so in the run’s degradation notices
Records
- Hash-chained audit log of every run, including who ran it and where
- Each receipt linked to its audit record, so a trimmed log is caught
- Software bill of materials produced at packaging time from what the binaries actually link, and signed
Security posture
- Signatures over PIGEON’s own artifacts are hybrid: a classical one, ECDSA P-384 with SHA-384, and a post-quantum one, ML-DSA-87. Verification requires both, so breaking either algorithm alone forges nothing — and the set of algorithms present is bound into what each signature covers, so the post-quantum half cannot be stripped off and the classical half passed off as a legitimate classical-only signature
- Optional FIPS mode using the OpenSSL FIPS provider; PIGEON refuses to run if it cannot load it
- No update checks, no crash reporting, no telemetry. PIGEON only ever reaches out to the host your own profile names, and only ever listens when you start one of the server modes above
- Hardened builds with standard compiler and linker protections
Where it runs
| Platform | Command-line tool | Graphical app |
|---|---|---|
| Windows 10, 11, Server 2016 and later | Supported | Supported |
| Modern Linux | Supported | Supported |
Need to deliver to older systems? Ask us about far-end support for legacy destinations.
What PIGEON doesn’t claim
PIGEON is not itself a validated cryptographic module, and does not claim to be. In FIPS mode it relies on the FIPS provider supplied by OpenSSL on the host, and will not start without it.
PIGEON does not grant an authorization to operate. It gives your assessors clear records, signatures, and documentation to work with.
Package signing and the audit trail are tamper-evident, not tamper-proof: they tell you a record was altered, removed or reordered. They do not stop someone with write access replacing the file wholesale. Host controls such as application allow-listing still matter.
Naming an algorithm is not a validation claim. The algorithms PIGEON signs with are published standards; that is a property of the algorithm, and says nothing about whether any particular implementation of it has been validated.
Talk to us about your environment
Tell us where the data has to go and what it has to cross. We'll tell you plainly whether PIGEON fits.