sntran
In my third year of college, around 2010, I found Erlang. A few years later, I found Elixir. I liked the ideas at once: many small processes, messages between them, and supervisors that restart a process when it fails. I wanted to build something with them.
But every time I wanted to spin up a quick experiment on a free evening, the onboarding friction felt disproportionate: matching compatible Erlang/Elixir toolchains, configuring releases, finding hosting, managing a VPS or container runtime, and handling deploy pipelines. For a casual idea, that first step was always a wall.
That led me down a rabbit hole: What would it take to make the BEAM truly portable—to build once and run anywhere with zero server or container management?
To see if this was even viable, I put together a minimal proof-of-concept running Phoenix LiveView on an ephemeral edge runtime without standard Linux servers, VMs, or containers.
The challenge, naturally, is reconciling the BEAM’s stateful, persistent nature and LiveView’s long-lived connections with an environment that manages no persistent infrastructure.
I’m currently expanding this into a broader runtime abstraction so developers can compile and run BEAM apps anywhere seamlessly, but before diving deeper into the technical architecture in future write-ups, I wanted to gauge community interest:
- Would a zero-ops, portable BEAM runtime change how or where you deploy small apps or microservices?
- Where do you feel the biggest friction exists today when deploying BEAM applications outside traditional VPS/container setups?
Curious to hear your thoughts and experiences.
In the meantime, I’ll leave this gem:
universal_server() ->
receive
{become, F} ->
F()
end.
Demo Link:
(Check the small table at the bottom of the page—it exposes the runtime environment details.)
The same build. A different cloud. We changed no line of the app.
An Erlang shell. No server answers it.
The VM is in the browser tab: 10,000 processes, crypto, and a static page.
Where Next?
Trending in Discussions
Other Trending Topics
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
Master modern tools, write cleaner code, and tackle real-world challenges with Manning books, videos, and courses. Start building today.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #ai
- #podcasts-by-brainlid
- #ecto-query
- #blog-post
- #elixirconf-us
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #elixirconf-eu
- #api
- #forms
- #security
- #metaprogramming
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Bringing learning, work and compliance together since 1987.
Producing high quality Elixir screencasts since 2017.
**Building the future of software with AI, trust, and human connection.**
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 5- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
sntran
To show what the runtime can actually do, I put together an interactive sandbox called Studio:
Think of it like a zero-install Phoenix playground. When you click through to launch an instance, it creates a fresh project in an isolated VM:
It requires no local Elixir, Node, or Docker setup. Would love to hear how the spin-up speed and compilation feel on your end.
rhcarvalho
Are you running the whole app on the client side? How do you isolate secrets or share state across clients (e.g. PubSub)?
sntran
On Cloudflare, it’s actually not running client-side at all.
When you hit the Workers demo, Cloudflare spins up a dedicated Durable Object with its own BEAM VM just for your session (at /t/NAME/), which stays alive for 30 minutes. Your browser is just acting as a standard, thin LiveView client over a WebSocket.
Because the VM lives on the edge inside that Durable Object:
Secrets: They stay on the server side in the isolate. The browser never sees them or executes the BEAM code. It just gets the usual HTML diffs.
State & PubSub: It’s standard Phoenix under the hood. If you open that same /t/NAME/ link in another tab, both connect to that same Durable Object, so native PubSub and in-memory state just work across those clients. Different visitors get separate DOs, so projects are isolated by default.
(The same demo can run purely client-side in the browser on GitHub Pages, where the VM runs in Wasm right in the tab.)
sntran
And here is LiveBook with executable code cells, running directly on GitHub Pages, i.e. directly on your browser! No server!
caleb-bb
I feel like this is a problem a lot of people run into when they try to leverage the BEAM. Both Nerves and LiveView Native (RIP) wound up finding ways to spin up portable BEAM instances in multiple places.