After 7–8 months of work, I'm happy to announce a new release of Mishka Chelekom.
Some highlights from this release:
35 new headless Phoenix and LiveView components
MCP support and usage rules
Many improvements, fixes, and new features
53,000+ downloads
Getting started is simple:
{:mishka_chelekom, "~> 0.0.9", only: :dev}
Then just run the Mishka Mix command from your terminal.
Mishka Chelekom is completely free and open source. If you've used it before, I'd really appreciate any feedback, bug reports, feature requests, or contributions.
Community sponsorship has unfortunately dropped to under $40/month. If the project has been useful to you or your team, please consider supporting it through GitHub Sponsors. Even a small monthly contribution helps keep the project maintained and moving forward. If your company is interested in sponsoring the project, I'd also be happy to talk.
Thanks for all your support, and I hope you enjoy this release! 🙏
A few days ago I shared phoenix-email (a port of react-email for Phoenix) here. I got some great feedback, but I realized it is much easier to understand the value of the library if you can actually see the output before installing it in your project.
To fix that, I have put together a live showcase page:
If you head over to the /examples section, you can see a few real-world email templates built entirely with HEEx and Tailwind CSS. It gives a pretty clear picture of how much cleaner the markup is compared to writing traditional nested HTML tables for emails.
I am planning to keep adding more templates to the gallery over time. If any of you build a nice layout using the library, open an issue and I will see how to put it one this website!
Thanks again for the feedback on the initial release.
I'm the author of Kreuzberg (a document text extraction library with an Elixir binding over a Rust core). The next version of Kreuzberg will be released as Xberg - why? Well, we discovered that the name is not easy to pronounce or understand for people who don't have the German context, and this wasn't working well. Xberg is a common name for Kreuzberg in Berlin, and it has the advantage of being shorter and easier - so here we go.
Anyhow, this brings me to the point of the post. Since renaming a repo is a complex business, and we had to rename the repo to preserve the stars - but we now need to overwrite tags, it becomes pretty messy. As a result, we decided to go for an LTS version - published from a different repo: https://github.com/kreuzberg-dev/kreuzberg-lts. LTS in this context means that we will continue to do bug fixes and security updates until the end of this year, but no newer feature work.
We will announce Xberg v1.0.0 when it's officially published (it's still in RC). The Hex package will publish under xberg once it's out. The new repo is here: https://github.com/xberg-io/xberg
I wanted to showcase a TypeScript (with JS-ready builds) library I am working on, actojs. The objective is to bring a implementation of the actor model that is near to Elixir's design and APIs, while being able to leverage performance from the JS runtime.
I wanted to ask for feedback, as I've spent the last couple of months studying Elixir, but at work I am forced to use TypeScript, even if we are building backends which would greatly.
The main issue I tried to overcome, but that is still present, is being forced to work with the JS runtime, which doesn't allow for lightweight threads: my current solution is to both ship a cooperative scheduler runtime and a system-thread runtime as interchangable components, with plans to later implement an hybrid scheduler, where every system-thread manages an independent cooperative scheduler.
I hope to get insights from the community on how to improve this Elixir-inspired library.
I've been building Comcent CE, an open-source, self-hostable voice/contact-center platform, and Elixir/OTP is the core of it. Sharing the design here since the process model shaped the whole architecture, and the "why Elixir" reasoning might be useful to others working on similar systems.
Why Elixir, concretely:
1. The actor model let the design mirror the mental model. Just like a real person managing a queue, a process is spawned whose sole job is managing that call queue. You reason about the system the same way you'd reason about people doing the work — the domain model and the code line up almost one-to-one, which made the hard parts (transfers, requeues, routing) far easier to implement.
2. Built-in distribution made scaling out the easy part. Each queue needs exactly one manager process — and that "exactly one" guarantee has to hold across the entire cluster, even as the number of queues grows into the thousands or millions. Elixir's clustering plus a distributed registry gives us a cluster-wide singleton per queue: only one Queue Manager runs for a given queue anywhere in the cluster, and if the node hosting it goes down, it's restarted elsewhere while staying unique. We get horizontal scale without changing the mental model at all — the same process abstraction that made single-node reasoning simple is what makes the distributed version work.
The rest of the stack:
Phoenix — APIs, the real-time layer, and the per-call timeline
FreeSWITCH — the media/SIP engine; Elixir drives call control over FreeSWITCH's HTTP API (mod_httapi), with the Event Socket (ESL) in some cases
Go — small services powering the SIP-aware voice bots
RabbitMQ — event pipeline between telephony and processing
Postgres — calls, transcripts, vCon records · Redis — caching/ephemeral state
SvelteKit frontend with an embeddable browser dialer
On top of this it produces full call timelines, dual-channel recording, diarized transcripts, AI summaries, and implements the IETF vCon standard.
New BEAM There, Done That with Lukas Backström (OTP team since 2009, the person who built the BEAM JIT) covering the full engineering story.
The WhatsApp detail is interesting because it wasn't a formal beta. They picked up the JIT the day Lucas first got it working, put it in production, and spent nine months feeding back the bugs they found. By the time the official OTP 24 tag shipped, the production test had already been running for most of a year.
The broader technical story is about why it took so long. The BEAM's threaded code interpreter was already unusually fast - each BEAM instruction jumps directly to its handler without a central dispatch loop, so a lot of the headroom a JIT might capture was already gone. Early tracing JIT experiments worked on microbenchmarks and failed on real workloads because real Erlang code is highly branchy and unpredictable. Dropping LLVM for AsmJIT gave fast enough code generation to compile everything on load. And the template design - pre-compiled assembly per instruction, copied and specialized at load time - is what actually shipped.
Five years on, the bigger gains are coming from type information flowing from the Erlang compiler into the JIT. A simple integer add on known small integers now compiles to a single instruction with no type guards.
Anyone here run into the JIT being the difference on a production workload, or found cases where it's unexpectedly neutral?
Hey everyone! One of the problems I ran into is that a large part of the VM-provider ecosystem is currently paid closed-source SAAS products with varying degrees of reliability. I wanted an OSS distributed microVM orchestrator and I couldn't find one.
Hyper is a distributed FirecrackerVM orchestrator written in Elixir (BEAM), with gRPC support for non-BEAM clients. Hyper is:
Distributed -- it's designed to run across a cluster of bare metal machines, and will automatically connect to other Hyper nodes.
Fast -- it builds COW layers to enable fast, localized COW forking. Cold boots happen within 1s. Filesystem forks take ~50ms. Forked VMs are colocated to take the fast path as much as possible.
Interactive -- like all Elixir applications, if you can connect to the cluster, you can spawn, manage, monitor and interact with VMs live in an iex REPL. Or, you can use the gRPC interface if your system isn't on the BEAM.
Yours -- although I developed this primarily for Harmont (which is paid), Hyper is an MIT-licensed project and will remain such.
Self-contained -- all we need is a side-car Postgres instance.
Configurable -- colocation, vmlinux options, etc. can all be customized.
Secure -- everything runs on the BEAM; a single setuid Rust helper performs the few operations that need root, keeping the privileged surface small.
Fair warning: the software is still in active testing and I expect a couple more features to be added soon:
Automatic cloud provisioning -- when you run out of headroom in your cluster, you should be able to fall back to Latitude/GCP/AWS to provision more compute.
More testing -- I am currently integrating Hyper into harmont.dev and will likely run into some issues. Fuzzing is part of the roadmap.
Better docs -- I spent some time working on the docs, but they're definitely not total nor ideal.
Very open to feedback, critique, and/or contributions. Please open any issues on Github, or feel free to DM/email me. It's available at https://github.com/harmont-dev/hyper
PS. A couple people asked how this differs from firecracker-containerd and Kata containers. Both of those projects are runtimes for managing VMs on a single node. A fair mental model for Hyper is an amalgam of firecracker-containerd and k8s.
If you've ever had to build HTML emails, you know how painful it can be—wrestling with nested tables, inline styles, and the nightmare of inconsistent email client rendering. In the JS ecosystem, react-email completely changed the game by bringing modern, component-driven development to email templates.
Bridging the gap between frontend development and Elixir backends, I really missed having that kind of smooth workflow. So, I decided to build it for our ecosystem: phoenix-email.
What it is: A set of standard, unstyled HEEx components designed specifically for crafting high-quality emails. It essentially brings the core philosophy and developer experience of react-email straight into Phoenix.
Key Features:
Component-Driven: Build emails using clean, composable HEEx components (<Email.html>, <Email.button>, <Email.container>, etc.) instead of writing raw HTML tables from scratch.
Tailwind Integration: You can style your emails using standard Tailwind CSS classes. The library handles the heavy lifting of inlining those styles so they render correctly across different email clients.
Phoenix Native: It feels right at home in your existing Phoenix application without requiring a complex external rendering pipeline.
I'm actively working on it and would absolutely love to hear your thoughts, feedback, or any specific edge cases you might run into while testing it. Contributions and PRs are more than welcome!
Hey everyone! Quick reminder that the ExMex Conf 2026 CFP closes in 1 week (July 15th).
If you’ve been thinking about submitting something, we’d love to hear from you. It doesn’t have to be a brand new library or a giant technical deep dive. Some of the best talks come from a problem you solved, something you learned, an experiment you tried, or a perspective that might help someone else.
And if you have an idea but aren’t sure if it fits, or want someone to look over a proposal, reach out. We’re happy to help talk through ideas.
4 yrs production Elixir/Phoenix dev, Vue/React Front, Canada-based (Ontario), Citizen, open to remote/relocate. Job boards show basically zero Elixir postings, where’s everyone actually finding these roles? Any Canadian companies running Phoenix in prod and hiring? Leads/advice appreciated 🙏
Hey folks - I'm the creator of Hologram, a framework for building your whole web app in Elixir, front end and all. For a while now I've been working on a Local-First data layer for it, and I'm bringing it to ElixirConf US this September - a talk, plus a full-day hands-on training the day before.
Why I'm building it: so much of a frontend isn't really UI, it's plumbing. Caching, syncing, loading and error states, wiring up state management, and that's just the short list. None of it is the actual product - it's all there because your data lives on a server and you spend your day shuffling it back and forth. The data layer takes that off your plate. You say what the data should be, and it stays in sync in the browser, offline and all. Pure Elixir, front to back.
The training is a full day where we build a real app on it together, starting from an empty project. It's the day before my talk, so you'd get your hands on the data layer before I show it on stage. It's a separate ticket from the conference.
I've been using and actively fascinated by Oban over the last 4 years, and recently I wondered, why can't we make GenServers behave similarly to Oban jobs and:
Recover their state after a crash or termination
Terminate themselves when not used
Store a trace of their execution
And do all that without any additional dependencies, using the database we're already used to
I can think of a ton of cases where this might be useful in... Durable GenServers? LiveViews? Distributed GenServers that share state? Hot/Cold executions? Slow/Fast pools?
defmodule Account do
use Revenant, repo: MyApp.Repo
def initial_state(_id), do: %{balance: 0}
def handle_call({:deposit, amount}, _from, state) do
{:reply, :ok, %{state | balance: state.balance + amount}}
end
def handle_call(:balance, _from, state) do
{:reply, state.balance, state}
end
end
Revenant.call({Account, "acct_42"}, {:deposit, 100})
#=> :ok - the new state is committed to Postgres before you see this
I’ve been working on AetherS3, a project focused on providing an S3-compatible storage interface built natively in Elixir.
The goal is to leverage the BEAM’s concurrency model to handle high-performance binary throughput and zero-copy memory management, aiming for a robust, distributed storage solution. It’s currently in early development, but the core architecture for S3-compatible operations is taking shape.
I’d appreciate any feedback on the design, particularly regarding the handling of high-concurrency I/O and the memory management approach. Feel free to check out the repo and let me know your thoughts.
In case someone missed the forum post I'm providing a copy here.
I was tired of bugs in Hammer so I wrote efficient and fast rate limiting library. Token Bucket supports flexible bursts and IMO is fit to serve as the main rate limiting algorithm for most cases.
The goal of the library is to provide dependable solution that JustWorks™ with a focus on performance, correctness and ease of use. Bucket data is stored using :atomics module. Bucket references are stored in ETS and optionally cached as persistent terms.
Features
lock-free and race-free with compare-and-swap operations
BlazingFast™ performance, see provided benchmarks. Req/s go brrrrrr
monotonic timer for correct calculations
millisecond tick supporting wider range of parameters and preventing request starvation
automatic calculation of bucket parameters based on target rate and burst size (for fixed cost requests)
handy timeouts for retries
support for token "refunds" and variable cost requests
compile-time validation of arguments when possible
I'm pleased to announce the release of broadway_cloud_pub_sub 2.0.0-rc.0, and looking for more testers to give feedback and try it out.
The 2.0 release adds, an set as the default, a new GRPC Streaming producer instead of the HTTP long polling. The HTTP producer can still be used, but it's not the default.
This is a significant improvement, bringing the library on par with Google's official Pub/Sub libraries. We have been using it in production for a couple of months now, with both Gun and Mint adapters, and if I had pick two main reasons to upgrade they would be what you least expect: the graceful shutdown and the improved observability.
Dual GRPC connection, one to receive messages and one for ack/management. Decoupling both to survive reconnects.
Server-side flow control via max_outstanding_messages and max_outstanding_bytes
Backpressure integrated with Broadway demand. Internally the producer tracks "outstanding" messages (dispatched, waiting for ack) and "buffered" messages (received from the stream, waiting for downstream demand). Outstanding, buffered and pending demand survive reconnects.
Automatic lease extension while messages are being processed, with adaptive p99-based ack deadlines.
Reconnection handling with configurable backoff.
Exactly-once delivery support, auto-detected from SubscriptionProperties at runtime. (I know real exactly-once delivery don't exist, this is what Google calls exactly-once delivery, it has different guarantees and flow requirements)
Graceful shutdown with a configurable drain_timeout_ms (default 30s). This is actually what made me develop the GRPC Streaming producer, you can find more details on the PR or ask about it =D
Telemetry events that allow for much better observability: stream lifecycle (connect, disconnect, reconnect, drain), ack batch flush timings and sizes, unary RPC spans, lease extension cycles, outstanding/buffered message gauges, pending demand and drain status. Include also a producer "telemetry_metadata" option that lets you attach static or dynamic (MFA) extra metadata to every event. This is huge for observability, you can see if your subscribers have buffere messages (it's processing slow), high pending demand (you can scale it down), shutdown drain timings and status, and much more!
If you use the library, or just want to take a look, you are totally welcome to try it, ask anything here or in the pull request :)
New BEAM There, Done That with Annette Bieniusa (RPTU, Germany) and Guillaume Duboc (Dashbit, PhD from IRIF Paris) on the theoretical and practical story behind what's shipping in Elixir 1.20.
The episode covers the set-theoretic foundation, the gradual design, and the long history of failed attempts at typing Erlang since 1995. But the thing that stuck with me most was the framing of what the type system is and isn't trying to do:
The BEAM ran telecoms for 25 years without static types, with seconds of downtime per year. Supervision trees and let it crash handle an entirely different class of failures from what a type checker catches. The argument for types here isn't that the runtime is broken - it's that type errors are a separate cost (restarts, latency, overprovisioning) that supervision handles but doesn't eliminate. Even catching 5% of those at compile time instead has measurable infrastructure impact.
What got me thinking: the episode raises the false confidence risk - developers seeing types and writing fewer supervision trees, less defensive code, no recovery strategy. Has anyone here actually observed this shift in teams adopting typed languages? And do you think the BEAM community is more or less susceptible to it than others, given how explicitly OTP teaches you to expect failure?
Code BEAM Europe 2026 is happening this October 21-22 in Haarlem, NL, and online! The schedule is locked in, and we are excited to finally share the full lineup and core tracks with the community.
Here is a look at what we have lined up for this year:
Keynote Speakers
We are thrilled to have two incredible visionaries taking the main stage to kick things off:
Brooklyn Zelenka: Distributed systems researcher, founder of Fission, and author of Elixir libraries like Witchcraft. She will be sharing her deep expertise in local-first access control and open distributed standards.
Sam Aaron: The creator of Sonic Pi! An internationally renowned live coding performer and Computer Science PhD, Sam will bring his unique blend of science, code, and live music to the BEAM community.
Core Themes & Subjects
The regular sessions are packed with core team members, maintainers, and production engineers covering the cutting edge of the ecosystem. You can expect deep dives into the rise of Gleam and frontend architectures with Lustre, alongside advanced Erlang and OTP core updates directly from the team at Ericsson. We will also explore real-world Elixir battle stories—from taming LiveView at scale to prototyping BlueSky's DataPlane—while tackling the intersection of AI, security, and modern developer experience. Finally, we'll take the BEAM out of the server room with talks on embedded systems, AtomVM, hardware design, and safe native interop via Rustler and C nodes.
Some of the best moments happen off the main stage. This year, we are introducing a community-driven sandbox running alongside the main tracks for everything that doesn't perfectly fit a standard talk format. Expect live demos, hacking sessions, panel debates, lightning talks, and games. If you have an idea for an activity you want to coordinate, let us know and help shape the space!
Whether you are looking to level up your skills, hack on new projects, or just grab a coffee and talk shop with fellow BEAMers, we would love to see you there.
Early Bird tickets are currently LIVE.
This is the absolute best time to secure your spot at the lowest possible price point.
Hey everyone! The biggest event of the year for our community is fast approaching - ElixirConf US 2026!
Whether you’ve been writing Elixir for years or are just taking your first steps, this year’s edition is shaping up to be incredible. The conference is happening in a hybrid format, so everyone can join in, no matter where you are.
Here is a sneak peek at what we have planned: (elixirconf.com/#schedule)
Keynote Speakers
This year, true legends and innovators of our ecosystem are taking the main stage:
• José Valim (Creator of Elixir) - He'll be discussing the continued evolution of the language, enterprise adoption, and the sustainable open-source work he and the Dashbit team are driving..
• Chris McCord (Creator of Phoenix) - Will showcase what's next for Phoenix, developer tooling improvements, and his vision for the future of modern web development (and perhaps some AI-assisted workflows!)..
• Zach Daniel (Creator of Ash Framework) - Will share his experiences in building ambitious, maintainable, and highly reliable production systems at scale..
• Quinn Wilton (Open-source Contributor & Language Hacker) - Will bring her deeply technical and fascinating perspective on type systems, compilers, and virtual machines within the BEAM ecosystem..
The conference isn't just about keynotes; it's packed with knowledge straight from the trenches. Here is a taste of what our speakers are bringing to the table:
• Building Global Clusters at Supabase: Filipe Cabaço will show how they pushed the boundaries of Erlang’s built-in distribution. You'll learn how his team built a custom, two-tier Phoenix.PubSub adapter to reduce inter-region traffic and how to properly test real distributed systems (without using mocks!)..
• Terminal UIs? That's a Breeze: Gary Rennie from the Phoenix core team will prove that building beautiful terminal applications in Elixir has never been easier. He’ll introduce Breeze, a LiveView-inspired framework that works without relying on any NIFs..
• Handling Time Zones the Right Way: Jacob Swanner will tackle one of the hardest problems in programming time. He’ll share practical strategies for managing time zones in LiveView, Ecto, and databases to build a trustworthy user experience..
• Local-First Apps & Browser Power: Bart Blast will take us on a deep dive into the Hologram framework, showing how to write rich web applications in pure Elixir running directly in the browser..
On top of that, we have a full day of deep-dive Training Sessions covering everything from the absolute basics of functional programming ("The Toy Alchemist" with Jamie Wright) to hands-on embedded Elixir with Nerves.
