As I generate more Elixir with AI, I wired up more automated quality checks than I've ever run to keep the code from drifting toward the median. Compile flags, Credo (Jump/Oeditus/ExSlop checks), Dialyzer, Boundary, Sobelow, audits, doc/test gates, all in one mix precommit. Each is linked to how it's set up in the real repo so you can lift what you want. What am I missing?

Creator of Hologram here. I just published a post about the project's funding and where it goes next - the short version:

Curiosum as Main Sponsor, the EEF's milestone program and the GitHub sponsors funded the most productive stretch in Hologram's history - four feature releases this year (most of the stdlib working in the browser, JavaScript interop, a full realtime layer, events and middleware), and the first production apps have shipped.

The EEF milestone round wraps up with v0.11. A second round is on the table, and company support earmarked for Hologram through the Foundation is what unlocks it. The next stretch is local-first, baked into the framework - and whether it gets built comes down to a few companies stepping in.

Full post: https://hologram.page/blog/backing-hologram

If your company uses Elixir and might want to back open source work, the post covers what sponsoring gets you. Happy to answer anything here.

Doing a little mini-series on distributed Elixir with some examples, starting with setting up your cluster and monitoring it

​Hey everyone,

​I’ve been working on AetherS3, a distributed, self-hostable S3-compatible object store built natively in Elixir. It leverages BEAM clustering and concurrency for data distribution and binary throughput without needing massive external orchestrators.

​I just pushed an update adding a couple of major components and want to get some feedback on the implementation:

* ​Granular Authentication / IAM: Moved way past simple credentials—it now includes users, group management, key minting, and policy enforcement to handle real access control. (Not yet IAM-compliant)

* ​Web UI: A sidecar dashboard to visually manage buckets, browse objects, and handle the new user/policy configurations, and an (elegant, i hope) way to see the cluster health in action).

​The repo is here:

https://github.com/wizenink/aethers3

​I’d love to get your thoughts on the approach, the UI workflow, or the policy engine design if you have a chance to take a look.

Hi! New to Elixir, but enthusiastic. I am hacking on a 2d grid-based MMO. Think 2d Runescape. I am trying to decide how to best utilize OTP. Two approaches come to mind:

1. A genserver per "entity". Actor-based architecture. A Goblin actor messages a Player actor messages an Arrow actor. I know the BEAM can handle many, many processes--but is this really the right approach for 1000s of arrows x 1000s of drops x 1000s of players x 1000s of etc? Does is scale to "massive multiplayer"?
2. A genserver per world chunk/room. Spatially shard the world via a dynamic supervisor. Each chunk holds its own state and messages neighbouring chunks when an entity crosses a border. This approach feels like it would cap out on inbox throughput of a busy world chunk.

Thoughts?

P.S. I know focusing on massive scale early on in a game project is a common folly, but humour me! Trying to make an MMO is also a common folly. :)

New BEAM There, Done That with Isaac Yonemoto (Zigler creator) and Garrison Hinson-Hasty (Systems Programming with Zig author) on native code integration and what Zig actually changes about the risk model.

The honest answer everyone wants to know: yes, a Zigler NIF can still take down the whole node. NIF code runs in the BEAM's process space, so serious memory violations can corrupt the VM. What Zig's safe release mode gives you is spatial memory safety - buffer overflows, out-of-bounds accesses, null pointer dereferences are caught and produce panics rather than silent corruption. What it doesn't give you is temporal memory safety (use-after-free), which is the class of bug Rust's borrow checker catches at compile time.

One thing I hadn't thought about before: Zigler uses the BEAM's own allocator by default, because Zig's allocator model is explicit (you pass allocators rather than calling malloc globally). That means native memory is visible to the VM's monitoring tools, unlike Rustler NIFs which typically use Rust's allocator and are invisible to the BEAM.

Four execution modes (normal, dirty CPU, dirty IO, spawned thread) are switchable per function with a single flag, no code changes needed.

Has anyone here shipped production Zigler code? Curious what the operational experience looks like - particularly around the dirty scheduler modes and whether the BEAM allocator integration actually helps in practice.

https://youtu.be/iLcZRpBEmgE

I call it Goose Panel. Started off as i wanted to be able to have access to the AI on my server, so i could continue work during my day job. And blossomed into this lovely idea. One of the biggest features, besides the AI Runner, is the AI Site Doctor.

AI site Doctor Panel

So what exactly is Goose Panel Fully?

GoosePanel is an industry-defining, modern server control panel built for the next generation of developers, sysadmins, and hosters. It replaces bloated, dated legacy tools (like cPanel and Plesk) with a lightweight, secure, and AI-first orchestration platform.

Some of the feature's include;

1. **AI-Native Server Management**

**Autonomous Runner:** Safely runs background AI agents to complete infrastructure tasks.

**Tool Scoping & Guardrails:** Restrict AI capabilities by setting exact path read/write privileges, preventing command execution drift, and enforcing hard policy gates.

**Realtime Streaming:** Live-streams command standard outputs, shell crons, and runner logs straight to the browser via Phoenix Channels/WebSockets.

1. **Modern Application Catalog**

**One-Click Provisioning:** Install, configure, and scale applications in seconds using Docker/Docker Compose templates.

**Pre-Configured App Catalog:**

**WordPress:** Click-to-deploy hosting setup.

**code-server:** Remote VS Code IDE in the browser (Port `8085`).

**Mautic:** Marketing automation and campaign manager (Port `8086`).

**Akaunting:** Local bookkeeping, invoicing, and accounting (Port `8087`).

**Owncast:** Self-hosted live-streaming and chat alternative to Twitch (Ports `8088` and `1935`).

**Ghost:** Node-based blogging engine.

**Roundcube Webmail:** Fully-configured webmail exposed publicly via automated Nginx SSL reverse-proxies.

1. **Monitoring & Healing (Site Doctor)**

**Uptime Probes:** Custom lightweight `/healthz` uptime checker (`bin/goose_uptime_check.sh`) designed to run independently of the main BEAM VM. Returns Nagios-compatible state codes (OK, Warning, Critical) to external alerting systems.

**Browser Checks:** Run headless Playwright scripts automatically to verify that user checkout, login, or pricing pages are visually correct and functioning.

**Drift Detection:** Scans servers for configuration changes that diverge from the git baseline.

Tech Stack
Backend Runtime: Erlang/OTP 26, Elixir 1.15+, Phoenix 1.8.

State Management: PostgreSQL with Ecto, Oban for high-reliability job queues.

Frontend Engine: Phoenix LiveView (providing single-page app speed without the bundle bloat of React/Node), Tailwind CSS v4, and esbuild.

Orchestration Engine: Docker & Docker Compose API, Stalwart (Mail Server), certbot, and Nginx.

https://reddit.com/link/1ux7rrl/video/rr3837oinedh1/player

Your Phoenix LiveView app disconnects from the server. the UI freezes, buttons stop working, nothing updates until the socket comes back.

Local LiveView (LiveView running inside Popcorn, in your browser) doesn't freeze, and when the connection returns, it doesn't throw away your state either.

We built a small burrito ordering app with a "disconnect" button baked in, so you can watch both versions handle the same disconnect live!

Hey folks. I'm the creator of Hologram, and my talk just went online.

Last year I made the case for Hologram - building your whole web app in pure Elixir, front end included. A lot has shipped since, and the next chapter is local-first.

So most of the talk is a tour of the local-first landscape. What the term actually means, why CRDTs guarantee convergence but not invariants. I also get into what the industry has settled and what's still unsolved. Then the edge Elixir has here that JavaScript stacks can't copy.

https://www.youtube.com/watch?v=qqpNovT7cys

As title says. Haven't seen any myself.

Is it possible?

Hi Elixir community,

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! 🙏

Hey everyone,

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:

https://phoenix-email.fly.dev/

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.

Hi all,

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

Hi everybody!

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.

The link for the repository is: https://github.com/gi-dellav/actojs

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.

GitHub: https://github.com/comcent-io/comcent-ce
Walkthrough (bare VM → first call): https://youtu.be/Cm4JDB95vpI
Website: https://www.comcent.io/

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?

https://youtu.be/dT-VmfYz98Q

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.

Hey everyone,

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.

Links:

• GitHub Repo:gabrielperales/phoenix-email
• Docs:phoenix-email.hexdocs.pm

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.

Submit here:
exmexconf.com

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.

Training: https://elixirconf.com/trainings/building-localfirst-apps-in-pure-elixir-with-hologram/

Happy to answer questions about Hologram or the training!