September 23, 2026
Technology Choices for Web Village
Web Village was created to be an easy-to-use website builder, that makes it easy for social benefit organizations of all types to maintain their website. We wanted to make sure that it is a very reliable and scalable so you don''t need to worry about your website performance. Finally, we wanted to have the ability to easily customize the website, first as a user of the system with configurable options to shape your website. Further have the ability to either customize the website code, or create new blocks or templates. Finally, have the ability to also do custom development.
Why Phoenix, Elixir and Liquid
We feel we have the technology mix that makes this possible. We chose to go with Phoenix / Elixir for our backend code, and Shopify's Liquid templating language to customize. The benefits include:
- Isolation - Many client sites, each with genuinely separate data.
- Simple editing - Resellers & non-developers customize templates without running code.
- Concurrent I/O - Feeds, federation, cross-posting, media— lots at once.
- Reliability - One tenant's bad data can't take down the others.
- Rich admin - A full editor without needing to call in developers
- Efficiency - Many tenants per server; bootstrapped economics.
Elixir runs on the VM built for many small, independent things at once
Elixir compiles to the BEAM — the Erlang virtual machine, built for telecom systems that stay up for years while thousands of independent connections come and go. On the BEAM, work runs as huge numbers of tiny, isolated processes — cheap enough to spin up by the million — each with its own memory and each scheduled fairly, so no single request can starve the others or take the whole system down with it. When something does go wrong, a supervisor simply restarts that one process while everything around it keeps running, and the rest of the site never notices.
That heritage is exactly the workload underneath a federated, multi-tenant platform. Every site we host, every visitor on it, and every background job — delivering a post to the fediverse, polling a feed, resizing an image — is one of those lightweight processes, kept apart from all the rest. The result is steady, predictable performance even under load. Where Ruby/Rails and PHP reach for external machinery — separate job servers, worker processes, add-on queues — to approximate this, the BEAM makes it the grain of the language.
| Elixir / BEAM | Ruby / Rails | PHP | |
|---|---|---|---|
| Concurrency | Millions of lightweight processes, true multicore parallelism. | Threads throttled by the GVL; parallelism via more OS processes. | Process-per-request; no concurrency inside a request. |
| Background work | In the VM. Fan-out is free; Oban adds durability — no broker required. | Sidekiq + Redis, a separate worker fleet. | External queue / cron + Redis; nothing survives the request. |
| State & cache | ETS, PubSub, Presence built in. The feed cache lives in-node — no Redis. | Multi-process → externalize to Redis. | Stateless by design → externalize everything. |
| Fault tolerance | Supervised processes restart; one failure stays isolated. | Request-scoped rescue; workers need outside supervision. | Request dies on error; no long-lived supervision. |
| Real-time UI | LiveView over persistent sockets, state on the server. | Hotwire / Turbo — HTML over the wire, lighter. | Livewire or hand-rolled JS bolted on. |
| Efficiency / cost | High concurrency per node — fewer, smaller machines. | Scale by adding processes & RAM. | Cheap per request; concurrency & state return as infra. |
| Multi-tenancy | Triplex — a Postgres schema per tenant, queries prefix-scoped; idiomatic in Ecto. | Row-level (tenant_id) by default; schema-per-tenant via the aging Apartment gem. |
Bolted on via tenancy packages (row-, schema-, or DB-per-tenant). |
The pattern: everything Rails and PHP solve with a queue, a broker, and a cache server, the BEAM solves inside one running system.
Phoenix LiveView - A real-time, full admin
The entire back office — the block editor, the page tree, drag-to-reorder, inline field edits, live validation, even the "is this owner email already an account?" check as you type — is LiveView. Interactivity is server-rendered over a persistent WebSocket, with state held on the server. There is no separate JavaScript app, no API layer to keep in sync, and no frontend build pipeline. The end result is that it makes for a much smoother admin experience.
- vs React/SPA: no duplicated client/server state, no API contract drifting from the UI, no framework churn to chase.
- vs Hotwire & Livewire: genuinely stateful interactivity, not just HTML fragments — the server holds the live model of what's on screen.
- It rides the runtime: each live session is one lightweight BEAM process, so thousands of concurrent editors cost almost nothing.
- Both rendering modes, one codebase: public sites stay server-rendered (fast, cacheable, SEO-clean); the admin is live.
- Room to grow for free: collaborative editing, live preview, presence and notifications come from PubSub/Presence already in the box.
Everything is under one umbrella: one language, one codebase.
Liquid lets non-developers customize — without the risk
The hardest constraint in a white-label platform is that people who aren't engineers — clients, resellers, designers — need to shape their own sites, and none of them can be allowed to run code on the server. Liquid (via Liquex) is templating built for exactly that: it's the language Shopify hands to millions of merchants. It renders semi-trusted input in a sandbox — no arbitrary code execution, no way to crash the render — which a full templating engine like EEx/ERB, being real code, simply can't offer.
On top of Liquid sits the block system: every block — hero, gallery, testimonials, the community feed, the showcase — is a small Liquid template with a declared set of fields. Non-technical users build pages by arranging and configuring blocks in the editor, never by touching code. New capabilities ship as new blocks, not a fresh deploy per site.
And because templates are data, not compiled code, the whole library is versioned and synced: a platform-wide fix or a brand-new block rolls out to every tenant, while any site can hold its own per-tenant override. Content and layout changes go live without a redeploy.
Sandboxed
Semi-trusted authors customize freely — no code execution, no crashes. EEx/ERB couldn’t be exposed this way.
Composable blocks
Each block is a Liquid template with typed fields; sites are assembled, not coded.
Templates are data
Versioned & synced — platform-wide rollouts, per-tenant overrides, changes without a redeploy.
Portable & extensible
Shopify/Jekyll lineage eases design and made migrating in feasible; custom filters & tags (markdown, image/alt, colour) extend it safely.
Tradeoffs
- Smaller talent pool than JS/Ruby/Python — but LiveView means you need fewer engineers, which offsets it.
- Fewer off-the-shelf libraries in some niches — occasionally you build or wrap rather than install.
- A functional / OTP learning curve — real, and it pays back in reliability and simpler concurrency.