OTPiser generates OTP supervision trees, GenServers, GenStateMachines, and fault-tolerance scaffolding from service descriptions — bringing Erlang/BEAM reliability to any service architecture.
The "let it crash" supervision tree model is genuinely superior for reliability, but OTP patterns are notoriously hard to learn correctly. Supervision strategy selection, restart intensity tuning, child spec ordering, and process linking are all sources of subtle production bugs. OTPiser eliminates the cliff.
Describe your services in otpiser.toml. OTPiser:
Parses your service architecture into a dependency graph
Generates an Elixir supervision tree with correct restart strategies (
one_for_one,one_for_all,rest_for_one)Creates GenServer modules for stateful service components
Creates GenStateMachine modules for state-machine workflows
Wires up
max_restarts,max_seconds, and child spec orderingGenerates health checks, circuit breakers, and backpressure mechanisms
Emits NIFs (via Zig FFI) for performance-critical hot paths
| Strategy | When OTPiser uses it |
|---|---|
| Independent services — restarting one does not affect siblings |
| Tightly coupled service groups — if one fails, restart the whole group |
| Ordered dependency chains — restart the failed process and everything started after it |
Application — top-level OTP application with
start/2callbackRoot Supervisor — entry supervisor with configurable strategy
Service Supervisors — per-service-group supervisors (nested trees)
GenServer workers — stateful services with
init/1,handle_call/3,handle_cast/2,handle_info/2GenStateMachine workers — state-machine processes with typed state transitions
DynamicSupervisor — for services that spawn workers on demand (connection pools, consumers)
Registry — named process registry for service discovery
Task.Supervisor — for fire-and-forget or awaited async work
Microservice resilience — describe your service mesh, get a battle-tested supervision tree
Message queue consumers — GenStage/Broadway pipelines with backpressure and consumer groups
Connection pool management — DynamicSupervisor pools with health-checked workers
Distributed system orchestration — multi-node process groups with
:pgand:net_kernelIoT device management — per-device GenServers under a DynamicSupervisor
WebSocket/long-lived connections — supervised connection handlers with clean shutdown
Follows the hyperpolymath -iser pattern (same as Chapeliser):
Manifest (
otpiser.toml) — describe WHAT you wantIdris2 ABI (
src/interface/abi/) — formal proofs of supervision tree correctnessZig FFI (
src/interface/ffi/) — C-ABI bridge for NIF generationCodegen (
src/codegen/) — generates Elixir modules, mix.exs, config, and testsRust CLI — parses manifest, validates, generates, builds, runs
User writes zero Elixir code. OTPiser generates everything.
Part of the -iser family of acceleration frameworks.
# Initialise a new otpiser manifest
otpiser init
# Edit otpiser.toml to describe your services# Then generate the supervision tree
otpiser generate
# Validate the manifest before generation
otpiser validate
# Build the generated Elixir project
otpiser build
# Show manifest info
otpiser info[workload]
name = "payment-gateway"entry = "PaymentGateway.Application"strategy = "one_for_one"
[data]
input-type = "PaymentRequest"output-type = "PaymentResult"
[options]
flags = ["distributed", "health-checks"]