Known limitations
Properties asobi does not enforce. Operators who care about any of these should plan their deployment accordingly.
Game-module trust assumption
Loaded game modules (Mod:tick/1, Mod:join/2, …) run inline in the match gen_server and have full BEAM access. A malicious game module can read public ETS, spawn arbitrary processes, talk to clustered nodes, and crash the lobby. Treat the game-module source as part of the trusted compute base — ship code reviews and signed releases the same way you would for the asobi binary itself.
For untrusted scripting (community-submitted maps, modder content) use the asobi_lua sandbox; Luerl runs scripts inside a hardened state with stripped-out OS/IO/code-loading APIs and a wall-clock budget per callback.
Distributed Erlang defaults
The shipped vm.args.src sets a node name and cookie but does not lock down the dist port range or bind EPMD to localhost. For single-node deploys, uncomment the localhost-bind line in vm.args.src. For clustered deploys, set an explicit port range and enable TLS for distribution — see the threat model for the exact lines.
OS-level resource bounds
asobi does not enforce per-process memory caps or BEAM-wide CPU caps. A malicious game module that allocates aggressively or spawns short-lived processes in a loop can pressure the OS allocator. If you run the engine alongside other workloads, isolate it via cgroups (systemd slices, k8s resources.limits) rather than relying on the runtime.
Container release tree is writable
The shipped Dockerfile runs as the non-root asobi user but does not declare --read-only. The README example mounts /app/game as :ro; that mode is the operator's responsibility, not the runtime's. We recommend docker run --read-only --tmpfs /tmp and chowning only the game directory to the runtime user (the rest of /app should stay root-owned + read-only).