Follow up from the GenStage explainer I put out a few weeks ago 🙃

My wife and I write a travel blog together. We both have photos and videos on our phones, but getting them into the same entry meant sending files back and forth every day.

So I wrote Texttile, an open-source blog engine in Elixir.

The collaboration model is deliberately small: one person holds the text editor, the other sees the words arrive and can take over with one click. Both can arrange photos and videos in the gallery while the text is being written. It is not simultaneous character-by-character editing by multiple writers.

Phoenix, LiveView, ffmpeg and SQLite run in one Docker container. The database and uploads live in /data. Videos are converted and played from your own server.

There are no roles or permission matrix. Everyone with an account is an admin. It is for people who trust each other.

The story and a video showing both screens: https://www.v01.io/posts/2026/08/texttile/

Source (MIT): https://github.com/texttile-blog/texttile

I'd like feedback on that handoff model. For a small shared blog, would you want both people typing into the text at once, or is taking turns enough?

I kept hand-rolling the same metering, plan-gating and billing layer in every Phoenix SaaS, so I extracted it. The free MIT core counts usage with an ETS update_counter (nothing on the database write path), gates features by plan with an atomic with_quota/4. A flusher persists snapshots on an interval, a broadcaster pushes live values over PubSub, and a LiveView component shows the usage bar moving within a second of the increment

```elixir 
AuroraMeter.track(org, :ai_generations)

AuroraMeter.with_quota(org, :ai_generations, fn -> generate_report() end) 
```

Roughly 7.9M increments/s across distinct counters on a laptop. Honest limits: counters are per node for now, and buffered mode can lose one flush interval on a hard crash (a durable mode exists for anything you invoice).

GitHub: https://github.com/liamkillingback/aurora-meter

Forum thread with the full design write-up: https://forum.elixirforum.com/t/aurora-meter-real-time-usage-metering-and-plan-entitlements-for-phoenix/76602

I open sourced ScopeStrength, a workout tracking and coaching platform I’ve been building with Elixir and Phoenix.

I posted about it here a while ago when it was a much smaller paid product. It has grown quite a bit since then, and I decided to open source it under AGPL.

The app works for both coaches and people training on their own. A coach can manage clients, build programmes, assign workouts, and track progress. Or you can build your own programme and log your training without a coach involved at all.

The entire application is built with Phoenix. There’s no separate frontend and no API layer.

I use LiveView for the UI, so there isn’t a client side application maintaining its own state and trying to stay in sync with an API. Most of the application logic just lives on the server.

Chat, notifications, and the unread badge all update in real time over WebSockets. Phoenix PubSub handles the fan out, so there’s no Redis or separate messaging service involved.

The app is also a PWA, so it can be installed directly to your phone’s home screen, and that is all served by the same Phoenix application.

There’s no AI in it either. Not because I have anything against AI, I just didn’t think this app needed it. You don’t have to put AI into everything.

The deployment is pretty boring too. It’s a Phoenix release and a PostgreSQL database.

No Redis, no Node process, no separate frontend server, no queue service.

This became especially important when I decided to make it self hostable. If someone wants to run it themselves, I don’t want them having to maintain a bunch of different services just to run a workout app.

One thing I’ve really enjoyed about Phoenix is how much you can build while keeping the architecture surprisingly simple. Real time features, authentication, database access, UI, background work and deployment all fit together really nicely.

I still think Elixir and Phoenix are one of the most underrated stacks for building applications like this.

https://scopestrength.com

GitHub: https://github.com/ebrahimgreat/scopestrength

Software Mansion is sponsoring ElixirConf next week, and instead of putting a screen on the booth and looping a demo, we're running the two days as an architecture clinic.

How it works: you book a 20-minute slot, you bring the part of your system that is actually causing pain, and one of our engineers sits down and works through it with you at the table. Afterwards we write up what we came up with and send it over, so you leave with something you can put in front of your team.

It's free and there is no pitch attached. We're doing it because these are the conversations we enjoy having anyway, and because a booth where someone actually helps you is more interesting than a booth handing out pens.

Slots are here: https://l.swmansion.com/KEPXa4

WhatsApp built a language server, type checker, and formatter for Erlang - then open sourced them. The reason they gave for open sourcing: keeping the tools internal would have made them worse, not better. Diverse use cases and external bug reports improve a tool. A captive internal user base doesn't.

New BEAM There, Done That with Roberto Aloi and  Michał Muskała on ELP and eqWAlizer. The rollout approach is the part worth discussing: when eqWAlizer introduced new type errors across teams, the developer experience team owned the cleanup, not the teams whose code broke. That's a very specific organizational choice about who bears the cost of tooling improvements - and it's why adoption worked.

Anyone running ELP against their projects yet?

https://youtu.be/LeIsRqjOQN8

Hey! At Software Mansion we've just released Legion, a library that puts AI agents inside your Elixir app, and we'd love to hear what you think.

Agents can build custom views, answer questions about your app, or act on users' behalf - in whatever mix suits you.

defmodule MyApp.Tools.PostsTool do
  use Legion.Tool

  def get_my_posts do
    %{id: user_id} = Vault.get(:current_user)
    Repo.all(from p in Post, where: p.user_id == ^user_id)
  end
end

defmodule MyApp.PostsAgent do
  @moduledoc "Answers questions about the user's posts."
  use Legion.Agent
  def tools, do: [MyApp.Tools.PostsTool]
end

Vault.init(current_user: %{id: user.id})
Legion.execute(MyApp.PostsAgent, "Summarize my posts from today")

Features TL;DR:

• Elixir modules as tools
• Agents as processes
• Agents write code that runs in a Lua (or Elixir) sandbox - the only way out is the tools you registered
• Agents can orchestrate other agents
• Persistence, rate-limiting, and authorization built-in

Play with the demo: https://legion.swmansion.com

Source: https://github.com/software-mansion-labs/legion

Docs: https://hexdocs.pm/legion

Happy to answer questions!

✏️ Phoenix's built-in LiveView test helpers require you to hand-build the form payload and start a fresh pipe after every click. Worse, that payload means a test can pass even when the button it "submits" was renamed.

phoenix_test writes the entire flow as a single pipe from the user's point of view and fails with a focused error instead of the entire page's HTML. I used it on my last side project, and I don't want to turn back.

https://mikezornek.com/posts/2026/9/phoenix-test/?utm_source=reddit&utm_campaign=phoenix-test

The Call for Contributions for BOB 2027 is open - Elixir submissions are very welcome!
bobkonf.de/2027/cfc.html

Adding a field to a message is easy. Supporting it while old and new producers are both running is the actual problem. For an additive schema change, there are four possible producer/consumer combinations during migration. The risky ones are the two mixed-version states.

A consumer-first rollout handles one of them deliberately: deploy a consumer that understands v1 and v2, then start upgrading producers.

That works well while compatibility is simple. With physical devices or other slow-moving producers, though, “temporary” backward compatibility can last years. Then translating legacy messages into a canonical schema before they hit business logic becomes worth considering.

We documented the approach here:
https://curiosum.com/blog/schema-evolution-in-distributed-async-message-passing-systems

https://com.erlef.org/wg/cna/2026/09/01/otp-updates.html

Hello.

This is my first fully functional product written in Elixir. I built it for myself, for monitoring jobs in my other projects, but I've decided to make it available for everyone.

It's cron job monitoring - job calls a url when it finishes, and if the call doesn't come on time app sends an alert. Each monitor is just a GenServer sitting on a timer. No polling the DB to find what is late.

It's free up to 20 monitors. You can test it and tell me what you think.

Feel free to leave comments, I'll appreciate your feedback.

Link to website: https://didit.run

I have spent the past 2 weeks experimenting with the idea of adapting the tiling model used by window managers like TUIOS or BSPWM. The experiment became Jigsaw.

Jigsaw represents the layout as a binary tree. The tree is then fed to a Phoenix component that will handle rendering the panes recursively using flexbox.

The layout is separated from phoenix deliberately in order to allow changes down the road where we want the tree to track dimensions of panes and other enhancements. A pane on the phoenix component should not care what is inside it. It can contain plain HTML or another liveview component.

For Example:

<JigsawComponents.Components.layout jigsaw_layout={@layout} >
  <:pane id="terminal">
    <!-- phoenix component that can be rendered in a slot -->
  </:pane>

  <:pane id="stats">
    <!-- phoenix component that can be rendered in a slot -->
  </:pane>
</JigsawComponents.Components.layout>

The current v0.1.0 is deliberately experimental and subject to a lot of breaking changes. I am currently building the demo application which I shall link when it is live.

Hexdocs: https://jigsaw.hexdocs.pm/

Github: GitHub - W3NDO/jigsaw: POC of a liveview tiling manager · GitHub

Happy to hear your feedback on architecture and API, and perhaps what you would build with such a library.

Also any mistakes and anti-patterns in the code are entirely my own lol.

Wrote about how to safely run a globally unique process in an Elixir cluster, and a scary story from the past!

Learn about `:global` for registering unique processes in a cluster, and where using it can go horribly wrong. Or at least, a little bit wrong. And how to avoid weird edge cases. This was a lot of fun and nostalgic to write, hope you enjoy it

Hi everyone! We (Software Mansion) are co-hosting an Elixir meetup with dscout at their Chicago office on Wednesday 9 September, the evening before ElixirConf kicks off. Doors at 6 PM, a few talks, then pizza and beer and hanging around talking to people.

Two talks confirmed so far:

• Dima Mikielewicz on Legion
• Leandro Pereira from Supabase on MDEx

We have one slot left and would rather give it to someone from the community than fill it ourselves. If you have something Elixir-related you've been wanting to talk about, let us know here: https://forms.gle/GNnzRXRwgdmeuggs5
It doesn't need to be polished, and a first-time talk is completely fine.

It's free, but places are limited by the size of the office, so RSVP here if you're coming: https://luma.com/byem6v75

Just a reminder for anyone still on the fence: early bird pricing for Code BEAM Europe closes on 8 September at 23:59 CEST. This is the last chance to get your ticket 20% cheaper before prices go up.

21-22 October in Haarlem + a full online option if you cannot make the trip. Two days of Erlang, Elixir and Gleam, real production stories, and demos from people building the tools we all use.

If you have been meaning to book, now is the time.

Register here: codebeameurope.com/#register

We hope to see you there!
The Code Sync Team

I have an elixir app running in production, and with some recent changes (mostly library updates due to CVEs) it's started leaking memory, which is resulting in pods restarting.

I think I know what the cause might be, but just wondering if there are any techniques for debugging this that I'm not aware of.

We're now just 10 days out from ElixirConf US 2026, and we wanted to give the forum a proper heads-up, with a little thank-you discount attached.

📅 Dates: September 10–11, 2026
📍 Where: Chicago, IL (and streamed live everywhere)

Two days of production war stories and real scaling challenges, deep dives into Phoenix, LiveView, OTP, Nerves & Nx, keynotes including "Set-Theoretic Types from Scratch" with José Valim, and hallway-track conversations with the people who maintain the libraries you actually ship on. Meeting the community in person is the part you can't stream - grab an in-person ticket while they last.

Not in the area? No problem. The virtual pass gets you every talk streamed live, the conference app, live Q&A, and early access to the recordings. Same content, from wherever you are.

See you in Chicago - or on the stream! 🔥
The ElixirConf US Team

An educational side project in Elixir, Phoenix, and Tauri. I share what I learned while wiring Automerge into the BEAM, including how I surfaced edit and delete conflicts for users.

I'm very new to the language and I'm very confused on some things. Coming from imperative langs, I'd assume that modifying tuples is very fast since they're basically just vectors. Unfortunately, they're also immutable like every other data structure in the whole language. So, if I want to make, say, a Canvas data type that holds all my pixels in a 2d data structure, is there literally no way to make it even if a little more efficient than just making a new one every single time I update a pixel? Even if I made it a 1d data structure, is Elixir just the wrong tool here?

I didn’t want to pay for Sentry, but I still wanted to know when something broke in one of my Phoenix apps.

I also didn’t want errors mixed into Slack or Telegram. I wanted a small, purpose-built iOS app that would send me a native push notification and keep the details somewhere pleasant to use. Software aesthetics matter to me - even for error notifications.

So I built Boop.

The server uses around 8 MB of memory on my self-hosted machine. It’s completely free and open source:

https://github.com/chrisgreg/boop

I also built a plugin for Elixir’s ErrorTracker:

https://github.com/chrisgreg/boop_error_tracker

Once connected, errors captured by ErrorTracker can be sent to Boop and delivered directly to your phone. For my needs, it’s basically a very small, self-hosted Sentry setup built around the Elixir tooling I already use.

The iOS app is open source as well. You can build it locally and install it on your own phone. The repository includes instructions for configuring private push notifications for your device, so you don’t need to publish anything through the App Store.

Boop isn’t limited to exceptions. You can also use it for anything else happening inside an application:

• Failed Oban jobs
• Deployments
• New signups
• Payments
• Low disk space
• Important application events

There’s a general Elixir client here:

https://github.com/chrisgreg/boop_ex

And a Node client here:

https://github.com/chrisgreg/boop-node

This was built primarily for indie developers and people who enjoy owning their infrastructure without turning it into another infrastructure project.

Everything is still new, so feedback on the Elixir integration, setup instructions, or the overall approach would be very welcome.