Proxylity's WireGuard listeners now admit strangers and hand each packet to Lambda

On June 3, Proxylity founder Lee Harding added two capabilities to the company's UDP Gateway: WireGuard endpoints that complete a handshake with clients whose public keys were never registered, and asynchronous delivery of those packets into AWS Lambda ^[1]. That pairing addresses the two structural reasons a freshly manufactured device could not talk to a serverless backend over UDP: it had nowhere to enroll before it existed ^[2][3], and the thing on the other end was waiting for a reply it could not usefully produce ^[8].

Until now, a WireGuard Listener required customers to list every permitted peer's public key in a CloudFormation template ^[2]. Fine for a fixed set of machines; a deployment bottleneck when a mobile app generates its keypair during installation, or when devices create keys on first boot ^[3]. The new `AllowUnknownPeers` property lets the Listener finish a handshake with any valid client whose key is absent from the configured list, with WireGuard still encrypting the tunnel ^[4]. Harding wrote in the launch announcement that "The analogy to HTTPS is intentional," drawing the comparison to a public web server that establishes TLS before it knows who the visitor is, and putting identity and authorization in the Lambda function or downstream workflow instead of at the network boundary ^[5].

The optional gate is `UnknownPeerPreSharedKey`, a single secret every unknown client must hold, while named peers keep individual secrets on the same Listener ^[6]. Harding is direct about the limits: it is a barrier, not strong identity, a leaked copy admits any holder, rotating it across a large fleet is its own operational job, and sensitive fleets still need per-device authentication, enrollment records and revocation at the application layer ^[7]. Read that as the honest version of the HTTPS analogy. Anyone shipping this without an application-layer identity story has moved the problem, not solved it.

The second change is the more consequential one for architecture. Lambda integration previously used synchronous `RequestResponse` invocation, so the gateway waited for the function and used its return value to send packets back to the client ^[8]. Setting `UseAsyncInvoke` switches to Lambda's `Event` mode, which per AWS documentation queues the event and returns a 202 without waiting for the function ^[9]. In Proxylity's implementation the gateway moves on immediately, the return value is discarded, and the originating UDP client gets no reply at all ^[10]. A single packet can therefore start a Step Functions state machine or an AWS Lambda durable function, which AWS designed to checkpoint progress and support executions lasting up to a year ^[11].

Proxylity's worked example is provisioning: a device generates a keypair on first boot, connects with a fleet-wide pre-shared key, sends one packet, and Lambda starts a workflow that registers the identity, issues a certificate, writes a DynamoDB record and sends a notification, with confirmation reaching the device by another channel afterwards ^[12].

The context is Harding's own history. Proxylity's About page credits him with running a global Wi-Fi platform at Eleven Software serving 9 million daily users and more than 10,000 RADIUS-over-UDP transactions per second ^[14], upwards of 864 million a day ^[18], before building serverless systems at Zapproved and spending over a decade on C++ at Autodesk ^[15]. He founded the Portland, Oregon company in 2024 because AWS had made HTTP-to-managed-compute easy while UDP applications still left teams owning servers, load balancers, capacity planning and patching ^[16][17].

Watch the failure semantics. The launch announcement cautions that AWS can retry failed asynchronous invocations ^[13], which means idempotency now sits with your provisioning handler, and a duplicate certificate issue is a quieter bug than a dropped packet. Watch pre-shared key rotation next: it is the piece the product deliberately leaves to you ^[7].