Welcome to GigaElixir Gazette, your 5-minute digest of Elixir ecosystem news that actually matters.

This week: black-box profiling reaches across live BEAM nodes, Phoenix keeps stretching into voice chat and static generation, and we explore what happens when Elixir starts to look less like a web stack and more like a runtime for browsers, automation, and AI agents.

Connected to a live BEAM node over Distributed Erlang. No source code access. No instrumentation. No agents. Pure black-box runtime observation that produced a concrete architectural recommendation: your schema registry is hitting PostgreSQL 354 times per observation window for metadata that almost never changes - move it to ETS. Giulia's Monitor container connects via Distributed Erlang, collects process-level snapshots, then escalates to function-level tracing. Seven observation sessions against Nexus (an Elixir API gateway) revealed the internal structure of code they'd never read. Process rankings showed which modules owned the hottest processes. Function tracing exposed that 87% of operations were reads (2,209 read operations vs 320 writes), and Ecto's pipeline added 1.38x overhead (3,485 pipeline calls per 2,530 actual DB operations). The workflow is command-driven: `giulia-observe start nexus@ip`, optional cookie and module tracing, then `stop` to finalize. First bug: Nexus used long names (`--name`), Giulia used short names (`--sname`)-Erlang refuses to connect across name modes. One flag change fixed it. Production debugging without vendor tools or SaaS overhead.

Read more →

Started with PHP on December 25, 2025. Had a working prototype by January 5. Then realized PHP isn't built for real-time chat. Explored Node.js next-runtime, WebSocket libraries, Redis pub/sub, queue systems, background workers. Too many moving parts for a solo project. Switched to Elixir in early January. Rebuilt everything from scratch. Never used Elixir before-learned the language, OTP concepts, supervision trees, GenServers, LiveView while building NowBlind. Worked 16-18 hours per day for two months. The stack handled everything: random blind text and voice chat, compatibility-based pairing, presence detection, friend requests, media sharing, moderation workflows, subscription-based creator feeds. BEAM manages lightweight processes for each user session. Phoenix Channels handle WebSocket connections. PubSub coordinates presence across nodes. GenServers manage matchmaking state. Ecto handles PostgreSQL persistence. No external queue systems, no Redis for pub/sub, no separate background job infrastructure. The runtime itself solves the problems the product needs to solve.

Read more →

JavaScript interoperability shipped, the most requested feature since Hologram's inception. Call JS functions, use npm packages, interact with Web APIs, instantiate classes, work with Web Components. All from Elixir code. Zero latency on the client side because the Elixir code compiles to JavaScript that runs in the browser. Special thanks to @robak86 for extensive API design help, @ankhers for Web Components support, @mward-sudo for language server compatibility fixes. Sponsored by Curiosum (Main Sponsor), Erlang Foundation (Milestones Sponsor), and GitHub sponsors, including Oban. Hologram compiles Elixir to JavaScript for client-side execution, think Elm or PureScript, but with Elixir syntax. This release bridges the gap between Elixir's functional model and JavaScript. You write Elixir, it runs as JavaScript in the browser, and now it can call native JS APIs directly. The API looks well-considered according to early community feedback.

Read more →

Autonomous AI agent that monitors RSS feeds, web sources, GitHub repos, Google services - accumulates knowledge in PostgreSQL, executes multi-step workflows on schedule, communicates via Telegram. Runs entirely on your infrastructure. Key architectural decision: the BEAM VM is the runtime, not a container for Python-style orchestration. Supervision tree starts 13 children: Repo (PostgreSQL pool), PubSub (config broadcast), TaskSupervisor (workflow execution), UsageTracker (ETS-based LLM call counters), Config.Loader (seeds environment variables into DB and ETS), LogBuffer (500-entry ring buffer), Google.TokenManager (OAuth2 with auto-refresh), RateLimiter.Server (ETS-based with periodic purge), SkillSupervisor (DynamicSupervisor for isolated skill execution), Scheduler (Quantum cron), SchedulerSync (syncs DB workflows into Quantum jobs), Gateway (Telegram long-polling bot), Endpoint (Phoenix LiveView admin UI). Typical workflow: collect 8 RSS feeds concurrently, deduplicate against memory, batch-score 20+ article titles in a single LLM call, pass top items through LLM transform with prompt template, send briefing to Telegram. Runs every morning at 7:00 with zero interaction. Supervision trees, ETS caching, GenServers, PubSub are the actual building blocks, not abstractions bolted on top.

Read more →

Static site generation and incremental static regeneration for Phoenix. Think Next.js ISR or SvelteKit prerendering, built entirely on the BEAM. Prerendered pages served from ETS memory cache achieve 5,000 requests per second throughput with 200-microsecond latency on Apple M1 Max. Dynamic full Phoenix rendering: 45 req/s. That's 110 times faster. Setup takes 5 minutes: add the dep, wrap routes in `prerender do ... end` macro, add the plug before the router, configure, run `mix phoenix.prerender`. Three-tier serving: ETS memory cache → disk → Phoenix fallback. ISR uses stale-while-revalidate with configurable TTL-next request serves existing content immediately while triggering background regeneration. Users never wait. Key features: cluster-wide locking via `:global.trans/2`, cache invalidation via Phoenix PubSub, LiveView compatible (prerender LiveView routes, static HTML includes `data-phx-session` attributes for normal hydration), atomic writes (write to `.tmp` then rename), concurrent generation with `Task.async_stream`. ETS-based locks prevent thundering herd. Been using it in production on several sites before packaging it for release.

Read more →

OTP 28.4.1 patches three CVEs you probably didn't know existed. The httpd server was vulnerable to request smuggling via duplicate Content-Length headers with different values-attackers could slip malicious requests past your reverse proxy.

The inet_dns_tsig module (undocumented, unused in OTP itself) had a validation bypass where error-coded requests skipped MAC verification entirely, potentially allowing unauthorized zone transfers or DNS updates.

The crypto engine_load memory leak is less dramatic but still production-relevant if you're using OpenSSL engines with incorrect commands.

These aren't theoretical. Aisle Research disclosed the httpd vulnerability through responsible disclosure, meaning someone found it in the wild.

Upgrade path is straightforward: OTP 28.4.1 patches cleanly over 28.4 using otp_patch_apply. The httpd fix is non-negotiable if you're running Erlang's built-in HTTP server (rare but not unheard of in embedded systems or legacy deployments).

The DNS module fix matters if you're doing custom TSIG implementations; if you don't know what that means, you're not affected. Key lesson: undocumented modules aren't necessarily safe modules. The inet_dns_tsig code existed in the codebase, unaudited and unused by core OTP, until someone actually looked at it. If you're reaching for obscure OTP modules to solve niche problems, assume they haven't been battle-tested the way GenServer or Ecto have.

Remember:

Source →

Deploy your next Elixir app hassle-free with Gigalixir and focus more on coding, less on ops.

We're specifically designed to support all the features that make Elixir special, so you can keep building amazing things without becoming a DevOps expert.

See you next week,

Michael

P.S. Forward this to a friend who loves Elixir as much as you do 💜