Why as2d
Verified against the software your partners actually run
Most AS2 products are tested against themselves. as2d’s test rig runs seven independent AS2 implementations in containers — spanning four crypto lineages (BouncyCastle/Java, Go, Python, Ruby/OpenSSL, JavaScript) — and exchanges live signed, encrypted, compressed messages with each of them in both directions on every release:
- phase2 / as2-lib (Java, BouncyCastle)
- OpenAS2 (Java, BouncyCastle)
- mendelson AS2 Community Edition (Java, BouncyCastle)
- pyas2lib / django-pyas2 (Python)
- Waarp AS2 (Go)
- the Ruby
as2gem - node-libas2 (JavaScript)
Where a counterpart deviates from the RFCs, that behavior is measured, documented, and — where safe — handled automatically or by a per-partner switch. See Interoperability and Working with specific products.
Built like infrastructure, not like a Java app from 2005
- One static binary in a small container. No JVM, no app server, cold starts in milliseconds, tens of megabytes of memory at idle.
- Durable by design. Outbound sends and asynchronous MDNs live in a persistent retry queue; kill the server mid-delivery and the exchange completes after restart. Replay protection deduplicates partner retries.
- Streaming-friendly. Large payloads are spooled, not held in RAM.
- Cloud-neutral core. Storage is pluggable: SQLite + filesystem for a zero-dependency single node, PostgreSQL for multi-replica, with optional Azure Blob payload storage and Azure Key Vault key storage. No cloud SDK ever touches the protocol engine.
Costs that match the workload
AS2 traffic is bursty. as2d’s smallest production profile is a single container with no external services at all; the Azure serverless profile scales to zero between messages and costs approximately nothing at idle. See Cost profiles.
Honest engineering
The protocol engine is built test-first with property-based and golden-vector tests, kept above 90 % line coverage, and every deviation a counterpart forced on us is recorded with the measurement that proved it. Security decisions (inbound security floors, receipt authentication, SSRF guards on receipt URLs, transient-only retries) are each pinned by regression tests.