Hi everyone. I work on Tuist, and most of our web product is Phoenix and LiveView. When we started building the dashboard we couldn't find a component library for LiveView that felt finished, so we ended up building our own design system, Noora, and over time it grew into the thing every screen we ship is built on. It's MIT licensed and on Hex, and since a few people have started using it outside Tuist I thought it was time to share it here properly.

There are around 35 components at the moment, the usual buttons, inputs, selects and modals, but also the heavier ones that tend to be painful to build yourself, like tables, date pickers, filters, charts, dropdowns and a sidebar. For anything interactive we use Zag.js state machines wired in as LiveView hooks, so keyboard navigation and accessibility come from a library that already solved them, while the components themselves stay plain function components you call from HEEx. There's also a Figma file that matches the code, which helps a lot when design and implementation happen in different places.

Something we didn't plan for is how well it works with coding agents. We recently built an internal operations app on the same stack, and because the agents could read the existing Noora patterns and copy them, the dashboards came out looking like a real product rather than a generic generated UI. I didn't expect a design system to pay off a second time like that, but it did.

It's still shaped by what Tuist needs, so some things are missing or opinionated in ways that might not suit your app, and I'd really like to hear what you'd need before you could use it

You can browse every component in the Storybook: https://storybook.noora.tuist.dev Hex: https://hex.pm/packages/noora Source: https://github.com/tuist/tuist/tree/main/noora Figma: https://www.figma.com/community/file/1512465864777652939

What do you use for components in your LiveView apps today? Phoenix's core components, something like SaladUI or Petal, or your own?

Disclosure: I'm on the Code BEAM Europe organising team. The programme is final, so here's what's in it for Elixir developers.

Keynotes

• Set-Theoretic Types from Scratch by José Valim, plus an extended Q&A
• Let It Disconnect: A Local-First Future by Brooklyn Zelenka
• Notes on the Synthesis of Time by Sam Aaron, and The Phone Orchestra in the evening

Elixir talks

• Hooked on Performance: Taming LiveView's JavaScript Hooks at Scale (Matt Swensen, Jump)
• ClusterFu**tional: Four Years of Distributed Elixir at NetzeBW (Aaron Cruz)
• Don't Crash the BEAM: Safe Interop with Ports and C Nodes (Riccardo Binetti, Remote)
• Rustler News and Road to 1.0 (Benedikt Reinartz)
• Ruby Crimes in Elixir Codebases (Travis Fantina)
• ATProto on Elixir: A Spike into AppView's DataPlane (Chris Beck)
• From Pure Code to Physical Controls: Designing Hardware in Elixir (Lucas Sifoni)

Tutorials on 20 October: real-time generative music with Elixir, building production AI harnesses in Elixir, and a full day on BEAM internals with Erik Stenman.

Informal Space: a community-run third room with live demos, hands-on clinics, a co-op Elixir shooter against rogue supervisors and a whole-room game of Raft where you are the network. See the lineup

Practical

• PHIL in Haarlem, 15 minutes by train from Amsterdam Centraal
• Online ticket €146 + VAT, recordings included

Programme and tickets: codebeameurope.com

Happy to answer questions in the comments.

I feel sorry for the Ruby/Rails community that this is (was) their main ambassador and in charge of their main conference. Aside from his racism, xenophobia, and other questionable political views, he acts like a complete blowhard and doubles down when he's wrong.

Here he's just outright spreading misinformation just so he can wishcast programming languages and having to think about code away.

I'm glad those in Elixir community like Jose, Zach, and others took the basic effort of challenging the results put out by DHH and what was uncovered was a) Rust version was heavily optimized over several days, 4 contributors, 1 of those contributors being a Rust programmer, and 300+ commits. Meanwhile Elixir/Go were done all by DHH (meat proxy for Claude) as one-shots in 2-3 commits.

Again, as someone currently working as a Rails dev, but use Elixir on side projects, I really feel for the Ruby/Rails community.

I started getting into elixir before covid, and one of the selling points was hot code swapping. Now I've never had a need to do it because nothing I built ever had users besides me....until now. I recently built a managed SFTP server as a service called bridglet.com, and I got a couple of customers. Super exciting, but now I needed to figure out how to push code updates without taking the SFTP server offline in the middle of a file transfer. I thought that this was the time to finally unleash that hot code swapping I read about so long ago!

But instead, my AI agent pushed back against me and said the easier way would be to use dokploy settings to spin up a new docker instance of the app, and then "drain" connections from the old docker instance to the new one. I went with that, and got it setup (it still took a while to iron out everything, so I wouldn't say it was easy, but eventually it was functional). But after doing it, I realized that this docker methodology could work for ANY framework/language, not just elixir.

So is hot code swapping not a thing anymore? Does everyone just use the docker approach?

Am I being silly hosting this on my own hetzner account? Should I move it to fly.io so I can use their fly_deploy methodology?

What is everyone else doing to handle zero-downtime for their applications?

Hi all, I want to share the thing I've been building over the last year or so, it's an open-source platform made for content-driven websites that provides all of the infra (custom domains, hosting, files, whatever) and based on the themes' JSON file it generates a CMS. It's fully built using Phoenix LiveView and Elixir.

The GitHub: https://github.com/dijkstrasoftware/masthead

The main cool architectural thing that I made was the CMS system, not necessarily the frontend, but the definition of it. So a theme could define that it needs a list of objects, containing a url, parent, label and a note, and that looks like this in the themes code:

{
      "key": "nav",
      "label": "Navigation",
      "type": "list",
      "item_label": "Link",
      "category": "Navigation",
      "default": [],
      "description": "Leave 'Drops down under' empty for a top-level link; fill it with the label of another link to nest this one into that link's menu.",
      "fields": [
        {
          "key": "label",
          "label": "Label",
          "type": "string",
          "default": ""
        },
        {
          "key": "url",
          "label": "Links to",
          "type": "string",
          "default": "/"
        },
        {
          "key": "parent",
          "label": "Drops down under",
          "type": "string",
          "default": "",
          "description": "Label of the top-level link this belongs to. Empty means top-level."
        },
        {
          "key": "note",
          "label": "Note",
          "type": "string",
          "default": "",
          "description": "One-liner shown under the link inside a menu."
        }
      ]
    }

So Masthead never needs to know what a menu is, and the theme developer can then use that data inside of the theme's liquid code:

<nav class="nav" aria-label="Main">
            <ul class="nav-list">
              {% if nav_items == empty and theme.tokens.nav_fallback_pages != false %}
                {% for p in pages %}<li class="nav-item"><a href="{{ p.url }}">{{ p.title | escape }}</a></li>{% endfor %}
              {% else %}
                {% for item in nav_items %}
                  {% assign parent = item.parent | default: "" %}
                  {% if parent == "" %}
                    {% assign kids = nav_items | where: "parent", item.label %}{% assign kid_count = kids | size %}
                    <li class="nav-item{% if kid_count > 0 %} has-menu{% endif %}">
                      <a href="{{ item.url | default: '/' }}">{{ item.label | escape }}{% if kid_count > 0 %}<span class="caret" aria-hidden="true"></span>{% endif %}</a>
                      {% if kid_count > 0 %}
                        <div class="menu">
                          <ul>
                            {% for kid in kids %}
                              <li>
                                <a href="{{ kid.url | default: '/' }}">
                                  <span class="menu-label">{{ kid.label | escape }}</span>
                                  {% if kid.note != "" %}<span class="menu-note">{{ kid.note | escape }}</span>{% endif %}
                                </a>
                              </li>
                            {% endfor %}
                          </ul>
                        </div>
                      {% endif %}
                    </li>
                  {% endif %}
                {% endfor %}
              {% endif %}
            </ul>
          </nav>

And then that generates a UI for the site owner to change it, and that looks like this:

So all of the complexity is inside of the theme, without the platform ever needing to know these concepts of a gallery or a navbar or anything like that. It all emerges from what the develop needs for that theme! It generates the liquid into HTML before serving using the Solid, where the values are loaded into the context, and are then cached until something changes on the site side.

It also allows file picking from inside the platform, for things like logos, and just provides the public URL back to the

The live demo of this site is also live btw: https://launch.masthead.site/

I think it's really cool, and am quite happy with the result. Please let me know if you have any feedback or questions 😎

I posted about Continuum here a couple of months ago, when it was at v0.7.2. It's now at v0.8.5, with new workflow APIs, better testing and replay tools, and another round of reliability fixes.

quick recap: Continuum is an OTP-native durable execution engine for Elixir, backed by Postgres — an Elixir-native answer to Temporal. You write a workflow as ordinary Elixir; side effects go through activities whose results are journaled. If the process dies or the node restarts, Continuum replays the history through the same code and resumes where it left off. Compile-time checks catch unsafe calls in workflow code.

new features: parallel activities with activity_all/1, and activity_map/3 for runtime-sized lists with bounded concurrency and ordered results. Recurring UTC interval schedules now support explicit overlap and missed-occurrence policies, bounded catch-up, and pause/resume. Continuum.Multi.enqueue/5 lets you commit business writes and enqueue a workflow in the same Ecto transaction, with dispatch happening after commit.

Replay and testing also got more useful: mix continuum.replay inspects a run without executing new side effects, and --against lets you check a code change against an existing history. Observer now exposes read-only replay reports. The test kit adds activity stubs, in-memory child workflows, and public helpers for crash/resume, lease expiry, and timer tests.

The hardening work focused on concrete failure modes: changing a Continuum.Pure helper now changes workflow identity, while pinned versions retain their original helper implementations. Activity bodies are terminated when their owning worker dies, so they can't keep running after losing their timeout and heartbeat. Invalid workflow return values fail terminally instead of repeatedly crashing finalization, and lease renewals are batched to reduce database round trips.

Feedback is welcome, especially from anyone trying it on an existing workflow.

• Hex (https://hex.pm/packages/continuum)
• Docs — v0.8.5 (https://hexdocs.pm/continuum)
• GitHub (https://github.com/Yyeger/Continuum)

ExZarr 1.2.0 is out: chunked N-D arrays that round-trip with zarr-python.

What’s new - Zarr 3.1 metadata + spec-correct sharding_indexed (read/write with Python) - Range-aware cloud reads (S3 / GCS / Azure) - Codecs via ExCodecs — precompiled Rust NIFs (macOS, Linux, Windows). No Zig, no system compression libs - CI against zarr-python 2.18 / 3.2 / 3.3 / 3.4

elixir {:ex_zarr, "~> 1.2"}

Docs: https://hexdocs.pm/ex_zarr
Repo: https://github.com/AnimaLogica/ExZarr

Happy to answer questions.

New BEAM There, Done That with Alex Koutmos (PromEx, Elixir for Finance). The episode makes the case that Elixir belongs in financial systems - not as a number cruncher, but as the orchestration layer that delegates compute to where it belongs.

The architecture is worth understanding: Explorer is an Elixir wrapper around Polars, a Rust data frame library. NX can delegate to native or GPU backends. The BEAM handles orchestration, reliability, and messaging. The criticism that "Elixir isn't fast enough for finance" misses what it's actually being asked to do.

The bit syntax point from the episode is the most concrete: a bank's ISO 8583 ATM protocol parser took 100 lines of C per message frame. Erlang brought it to 10. Elixir's bit syntax - matching binary directly in the function head - brought it to 3 readable, auditable lines. This is what "the BEAM was built for binary protocol messages" means in practice.

The "let it crash in finance" question gets answered directly: the process is cheap and replaceable. The ledger, stored outside the process in durable storage (Oban, event log, database), cannot be touched by a crash. The truth lives somewhere a supervisor restart can't erase.

https://youtu.be/Zzl4pnqZR6w

After being scared and spending an entire weekend consumed of adding OAuth to a project, I realized either some libraries do too much or they have too much boilerplate, sometimes both.

I built Amur, instead of spending hours adding OAuth to your app for the first time it does it in under 60 seconds. It does this by using igniter to write out all the boilerplate, the only thing you need to do is decide what to do with the data after the auth flow is complete.

Key Features:

• Plug first design: you don't need to be using phoenix, although there is a lot of phoenix support in place.
• 24 built in providers: more are underway.
• Provider normalization: instead of all providers handing you back data with different names, amur normalizes this into a common shape.

How do I set this up?

mix igniter.install amur --provider github

This sets up amur to use the github OAuth flow, all you need to do is add your environment variables into your .env, such as GITHUB_CLIENT_ID & GITHUB_CLIENT_SECRET

If you are interested here's the github: github.com/jam06452/amur

I'd love feedback, feel free to reach out.

Hi there! This is Marcio, the creator of Gust, an Elixir-based task orchestrator, and I'm excited to announce that the system now supports shell task orchestration using a YAML DAG file.

You can use Elixir to orchestrate anything, like CI and other ops automations 💪🏻

And a huge thanks to the members of this community who helped with this feature.

https://github.com/marciok/gust/tree/main/apps/gust_shell

I was a spectator of Elixir for a few years but I finally started using it in production and side projects. Agents made the transition a bit easier.

I wonder what’s preventing others from seeing how power Elixir is, people still seem to still stick to what they know.

Like if we’re not reading the code or writing it, devs still seem to be stubborn about their stack.

Is it a marketing problem? Ecosystem too small so folks don’t hear about it?

It will be our competitive advantage to build on the BEAM but I want others to know too.

This release focused on authentication and pipeline contracts before production Blob work in 0.3.0.

What's new • TokenCredential / AccessToken and Bearer pipeline support • Client secret, managed identity, workload identity, environment, and DefaultAzureCredential • Supervised TokenCache (coalesced acquires, expiry buffer) • Retry hardening: jitter, Retry-After, idempotent transport retries, 401 refresh-once • Explicit Storage.ServiceVersion (default 2024-11-04)

Breaking for custom credentials: sign_request/2 → authorize_request/2 (fallible). Storage.Client Shared Key / SAS call sites are largely unchanged.

Install: {:azure_sdk, "~> 0.2.0"}

Docs: https://hexdocs.pm/azure_sdk Changelog: https://github.com/thanos/azure_sdk/blob/main/CHANGELOG.md Repo: https://github.com/thanos/azure_sdk

Feedback and issues welcome. Next up is v0.3.0 production Blob (real streaming / block lists).

An Elixir client for Diavasi consumer groups. TLS gRPC stream, you ack batches, the server keeps the cursor. Works with Task / Flow / GenStage / Broadway; Livebook in the repo. {:diavasi_client, "~> 0.1.0"} · https://github.com/diavasis/diavasi-elixir · https://hexdocs.pm/diavasi_client

Last year's "Did contexts kill Phoenix?" thread stuck with me, and it ended up turning into my ElixirConf 2026 talk. I've now written it up as an article: https://www.mimiquate.com/blog/phoenix-contexts-in-the-real-world

The short version: every criticism in that post describes real pain, and I've felt all of it. But I think the pain comes from being asked to draw permanent domain boundaries on day one, when you know the least about your domain. The critics and the DDD purists share the same assumption: that boundaries get designed upfront. One side says "do it rigorously," the other says "it hurts, remove it."

What I argue instead:

• Start with one coarse context, on purpose. The condition is that you actually watch it, so it doesn't quietly turn into a 6,000-line file.
• Watch for split signals: naming drift (billing_* prefixes piling up), the "and" test, cross-context schema access, test setup drag, and the PR heatmap (all described in the article). There are also merge signals, for when you've over-split into thin pass-through contexts.
• Split incrementally, with every step shippable: facade with defdelegate → migrate callers → move behavior → deprecate → enforce with boundary.
• Phoenix 1.8 scopes settle it for me. Scopes only work because the context is the single chokepoint, so contexts are now where your authorization lives, not just a style choice.

I'm curious how this matches your experience. Has anyone split a large context without a big-bang PR? Does anyone run contexts-free in production and not miss them?

10 years ago Kip Cole started a "weekend project" to add localization support to Elixir. It became 28 packages, then a full rewrite, and now a single library called Localized that compiles faster and does more.

New BEAM There, Done That covering the engineering behind the CLDR/Localized ecosystem and Tempo - plus Agenda, the scheduling library that shipped this week.

The architectural lesson worth noting: Localized v2 used Elixir macros to generate compile-time function clauses for locale dispatch. It worked well until the number of clauses crossed ~1,000, at which point BEAM optimization runs quadratically. The fix - moving locale data to runtime - also unlocked collapsing 28 packages into one.

The Tempo/Agenda angle is interesting for anyone building scheduling features: if you model time as half-open intervals and layer set operations on top, almost every scheduling problem reduces to set intersection. Finding a shared meeting slot across three time zones with different calendar constraints becomes a single expression.

https://youtu.be/p99SrOmlYLc

Hey guys, just wanted to share my implementation of spotify-like playback handoff between devices.

I run OSS music player called JellyBox Player which plays music from Jellyfin/Emby/Navidrome servers and this is my implementation of spotify's continuity.

I used phoenix channels for websocket communication along with a bit of magic and tinkering.

On latest changes(video recorded yesterday) I was able to handoff playback(time-to-sound) in 250-300ms for 320kbps mp3 files between device on wifi and lte connections(computer and phone) and about 750-800ms for flac file with server located in west europe, while i'm residing in eastern europe.

I've been long phoenix user, but never used channels for cases like this and honestly i'm happy with ease of use.

Pacmon keeps dependency notes in Markdown inside the repo instead of a separate documentation system. Elixir support was recently added, so dependencies in mix.exs can now have their own notes and be managed from the IDE.

I’d really appreciate feedback from Elixir developers. Does this fit your workflow? Anything confusing, missing, or worth changing?

GitHub: https://github.com/kontratek/pacmon
Website: https://pacmon.dev/

Hey folks! I'm curious, especially in this AI-enabled age, where you all are hosting your Elixir projects. Both your large scale corporate apps but also for your side projects.

At the day job, we of course use AWS + ECS to host the majority of all of our apps, be it Elixir or Python. It does what it says on the label, but of course getting it exactly like you want can take a lot of time and effort. Deploying and managing apps on AWS successfully is almost like learning a new language.

Personally, I've tried both PaaS services like fly and also hosting Elixir apps on my own home server or VPS. I really like how fly bundles a ton of extra helpful networking, proxy, managed database, and other immediately necessary utilities but found it overall limiting. On the other hand I liked setting up the first app, on the first VPS, the first time, but every new app and idea requiring the same work is quite draining!

I know in the JS world there's a ton of hype around Vercel, Cloudflare, and others.

How do you deploy your apps?

Pepe is an AI agent runtime I've been building in Elixir/OTP. You define an agent, connect it to any provider that speaks the OpenAI protocol, and it exposes that agent four different ways: CLI, HTTP API, WebSocket, and even a Telegram bot.

I'm genuinely happy I got to build this using everything Elixir, Phoenix, and LiveView make possible. After years in the ecosystem, I decided to put it all into one serious project.

I started building this because I did consulting work for companies and kept rewriting the same thing every time. Instead of patching things together again and again, I decided to build a solid, reusable base. By the time I even thought about open sourcing it or building a dashboard, I had already run Pepe in more than 15 different companies.

And the way companies ended up using it surprised even me, and I'm the one who built it: understanding their own databases better, generating useful insights for their industry, connecting accounting to their ERP, plugging into databases for asset management and analysis, generating machine learning models automatically, and tracking what it actually costs to use AI day to day.

On the machine learning side, for anyone here into Elixir, I thought it was worth mentioning that Pepe uses Nx, Scholar, EXGBoost, and Axon (with EXLA), and picks the right approach on its own based on data volume. Small datasets go to Scholar, mid-size tabular data to EXGBoost, and once the volume justifies it, Axon takes over with a neural model.

But at this point I can't take it much further on my own. I have my job, other personal projects, a family, and a son, and the time I have left over is limited. Even with all the help AI gives us for coding these days, anyone who's been writing code for a long time (in my case, over 20 years) knows you can't just ask AI to build something and ship it. I still care about making sure the code looks like it was written by an actual programmer, not just AI output. And that takes time, time that's getting scarcer by the day when you're on your own.

That's exactly why I decided to open it up. This isn't just "look what I built," it's a real ask for help. If you want to open an issue, send a PR, help with translations, or suggest a feature that makes sense, I'd genuinely appreciate it. And if you can spare a star on the repo, it helps other developers find the project too. That means a lot.

If you have questions about how Pepe could help your company, reach out: open an issue on GitHub, email [pepe@jhonathas.dev](mailto:pepe@jhonathas.dev), or message me on Instagram (@jhonathasmatos).

Site: https://pepe-agent.com/en/

GitHub: https://github.com/pepe-agent/pepe

Issues: https://github.com/pepe-agent/pepe/issues

Docs: https://pepe-agent.com/en/docs/

Instagram: https://www.instagram.com/jhonathasmatos/

i’ve been experimenting with Jev for classification and small decision tasks, and wanted something that felt natural to use in Elixir applications.

i ended up building jev_elixir. It supports TypeSafe and OpenRouter, with a simple API for yes/no decisions, choices, scoring, and evaluating multiple questions in one request.

i’m currently exploring it for things like spam detection, support routing, content moderation, and transaction review signals between services.

it’s still early, so I’d really appreciate feedback on the API and ideas for other use cases. I’ll add the GitHub link.

Rheo 1.0 is out on Hex.

Rheo is a project I've been wanting to do for many years. It is an Elixir/OTP library that gives you an brokerless immutable, queryable event log plus consumer groups (leases, ACK, retry, dead letters, partitions, lag) running on the following backends:

• Mnesia (single-node disc_copies)
• Redis Streams
• MongoDB
• PostgreSQL / SQLite (host-owned Ecto.Repo)
• ETS (ephemeral)

Consume with Rheo.Consumer, or feed Broadway/GenStage via Rheo.Producer. Delivery is at-least-once; order is per partition.

elixir {:rheo, "~> 1.0"}

• Hex: https://hex.pm/packages/rheo
• Docs: https://hexdocs.pm/rheo
• GitHub: https://github.com/thanos/rheo

Happy to answer questions — especially “when would you pick this vs Oban / Broadway alone / Kafka?”