What happens when two of the most interesting recent Elixir packages join together? Introducing durable_stash, our vibecoded approach to fixing one of the most annoying Phoenix LiveView problems: your assigns keep dying. Navigate away and they’re gone. And after every deploy, that setting your user carefully configured five minutes ago is back to its default.

The two packages in question:

• LiveStash (Software Mansion) has a lovely API for stashing and recovering assigns. But the stock ETS adapter only recovers on reconnects, deletes the stash on every fresh mount (by design, their README says to use URL params for navigation), and like everything in BEAM memory it dies on deploy.
• DurableServer (Chris McCord) gives you durable processes persisted to S3-compatible object storage. Durable Objects, basically, but on the BEAM.

durable_stash is a LiveStash adapter backed by DurableServer. One durable process per browser session, shared by every LiveView of that session:

defmodule MyAppWeb.SomeLive do
  use MyAppWeb, :live_view
  use LiveStash, adapter: DurableStash, stored_keys: [:count, :username]

  def mount(_params, _session, socket) do
    socket = assign(socket, count: 0, username: nil)
    {_status, socket} = LiveStash.recover_state(socket)
    {:ok, socket}
  end
end

A plug drops a random sid into the cookie session, the adapter hashes it into a storage key, and from then on your stored assigns survive live navigation, Wi-Fi hiccups, LiveView crashes, and full redeploys. Cleared cookies or another browser means defaults again. Which is the point. It’s session state, not a database.

Some details I’m happy with:

• Each stored key declares a recovery scope, because settings and form drafts want different policies:

stored_keys: [
  theme: :session,    # recovers on every mount: navigation, crashes, deploys
  draft: :reconnect   # recovers only on rejoins; clears on fresh navigation
]

A :reconnect draft survives a deploy mid-edit (the browser stays on the page and rejoins), but navigating to the form fresh starts blank. That’s stock LiveStash semantics, per key, with deploy survival on top.

• Writes are per-key diffs merged by a single actor, so two tabs writing different keys can’t clobber each other. We looked at CRDTs for this and rejected them: one process per session means there’s nothing to merge.
• Values are JSON-normalized at stash time. What you recover in dev is byte-for-byte what you’d recover after a redeploy in prod, so you don’t get atom keys in dev and string keys in prod.
• There’s a vsn/migrate option for when your stored shape changes.
• It ships an in-memory DurableServer.StorageBackend with proper etag CAS, so your tests need neither S3 nor LocalStack.

About “vibecoded”: yes, Claude wrote most of it. The test suite is real though: 40 tests including a deploy simulation (two DurableServer supervisors sharing one backend, stop the first, recover on the second) and actual Phoenix.LiveViewTest lifecycle coverage. We also ran it against a local S3 container and killed the VM between write and read.

It’s a 0.1 and young. On the roadmap: atomic update/3 inside the session actor, PubSub broadcasts for live multi-tab convergence, TTL/idle-stop, and a :permanent scope for user-scoped (not session-scoped) keys.

Hex: durable_stash | Hex
Docs: durable_stash v0.1.1 — Documentation
GitHub:

Feedback very welcome, especially from anyone using LiveStash or DurableServer in anger.