Igropyr: New Erlang-Style Webserver Built in Scheme
12 Jul 2026
A new entrant in backend infrastructure
A project called Igropyr has been announced as an Erlang-style webserver written in pure Scheme. It runs on the Chez Scheme compiler with FFI bindings to libuv, the same event-loop library that powers Node.js. The pitch: combine Node.js-style asynchronous I/O with Erlang/OTP's fault-tolerance model in a single Scheme-based system.
Exact announcement date was not provided in available materials.
What Igropyr actually does
According to the report, Igropyr's core design centers on a supervised worker pool. Every incoming request runs inside this pool, and if a handler crashes, the system is designed to recover automatically rather than taking down the whole server — a direct nod to Erlang's "Let It Crash" philosophy.
The project also implements what it calls a "gone guarantee": if a process dies for any reason — crash, TTL expiration, or normal completion — it gets unregistered, and any later attempt to resume that process simply returns "gone." This is meant to give developers predictable behavior around process lifecycle rather than ambiguous failure states.
Igropyr draws explicitly from three sources of inspiration:
- Node.js — for the event-loop and libuv-based architecture
- Erlang/OTP — for the actor model, supervisor pattern, and crash-recovery philosophy
- Swish, an existing Chez Scheme system — described as the concrete blueprint for Igropyr's scheduler, its
receivemacro, and its supervisor implementation
The numbers so far
A few configuration defaults and one benchmark result are available:
- Default port for
app-listen: 8080 - Default "stuck" timeout: 3,000 milliseconds
- Default health-check interval: 1,000 milliseconds
- In one benchmark of 50,000 requests at 500 concurrent connections, zero requests failed
No details on the hardware, network conditions, or request types used in that benchmark were provided, and there's no published comparison of latency or throughput against Node.js or Erlang/OTP.
Why founders should care
For early-stage teams evaluating backend infrastructure, Igropyr's supervisor-based crash recovery model could plausibly reduce operational overhead when handling failures — a common pain point for lean teams without dedicated SRE resources. Because it borrows the libuv/event-loop architecture familiar from Node.js, teams already comfortable with that paradigm may find onboarding easier than adopting Erlang/OTP outright.
The zero-failed-request benchmark is a promising early signal, but it's a single data point under specific and undisclosed conditions — it likely does not generalize to diverse production workloads without further independent testing. Founders considering Igropyr for anything customer-facing should treat this as a reason for cautious interest, not a production-readiness guarantee.
Most importantly, there's currently no public information on who built Igropyr, what license (if any) governs its use, its release or version history, or any real-world deployments. For startups that need long-term support guarantees or predictable maintenance, this absence of basic provenance and licensing information likely represents a meaningful adoption risk until more context emerges.
The gaps worth watching
Several open questions remain before Igropyr can be seriously evaluated for production use:
- Who created it, and is there a team or organization behind ongoing maintenance?
- Is it open source, and under what license?
- What are the benchmark conditions in more detail — hardware, network, request complexity?
- How does it actually perform against Node.js or Erlang/OTP on latency and throughput?
- Has it seen any real-world deployment outside of initial testing?
Bottom line
Igropyr represents an interesting architectural experiment — merging Node.js-style I/O with Erlang-style fault tolerance inside Scheme — and Swish's prior work suggests the underlying patterns aren't unprecedented. But with no team information, licensing clarity, or independently verified performance data yet available, founders should watch this project rather than bet critical infrastructure on it just yet.