BeaconCMS/beacon

Beacon is a Phoenix-based CMS and web framework that enables the creation of dynamic, live-updating websites using Phoenix LiveView. It provides a comprehensive content management system with support for custom templates, media libraries, and declarative action execution. The system features a modernized architecture with a platform-agnostic template AST, a GraphQL data layer, and a native CSS compiler for Tailwind styles, all managed through a centralized configuration and lifecycle hooks.

17 changes.

This period focused on modernizing the codebase by upgrading to Phoenix 1.7 and LiveView 1.0, which necessitated the removal of legacy Ecto schemas, templates, and web modules. The work introduced the foundational Beacon CMS core library, including lifecycle management, caching, and content handling, while simultaneously expanding the test suite to support the new architecture.

20 changes.

This period focused on significantly expanding the Beacon platform's capabilities by introducing new content models for redirects, A/B testing, and event handling, alongside a refactored template engine supporting custom Elixir snippets. The media library was redesigned to support external storage providers and automated image processing, while comprehensive test coverage was added across the new lifecycle, template, and type systems.

23 changes.

This period focused on building a new GraphQL data layer and a native Zig-based CSS compiler to replace legacy rendering and compilation pipelines. The work introduced declarative action execution, runtime page rendering via ETS, and comprehensive test coverage for the new architecture.

A new template for the Beacon router scope has been added to the installation process. This template generates a router scope that pipes through browser middleware and configures a specific site using the provided path and site name, enabling users to easily set up site routing during the initial installation.

priv/templates · medium confidence

The beacon\_css native module now includes a standard Zig build system (build.zig and build.zig.zon) that defines the library target, configures unit tests, and specifies a minimum Zig version of 0.15.2. Additionally, a .gitignore file has been added to exclude build artifacts (.zig-cache/ and zig-out/) from version control.

native · high confidence

The Beacon client SDK now includes a built-in set of template filters (date, text, number, collection, and utility) and a LiveView compiler that renders a platform-agnostic JSON AST into Phoenix LiveView \%Rendered{}\ structs. This enables consistent data transformation and efficient template rendering across all client SDKs.

lib/beacon/client · high confidence

A new \Beacon.Web.Cache.Stale\ protocol and its \Any\ implementation are introduced in \lib/beacon/web/cache/stale.ex\. This adds the ability to generate ETags and last-modified headers for Ecto schemas, enabling more efficient browser caching and cache invalidation for the web layer.

lib/beacon/web/cache · high confidence

Introduces new UI components in the web layer: a non-blocking CSS warming template that displays a loading state while assets compile, a default update notification component that appears when a page is updated in live mode, and layout helper functions for rendering dynamic page titles and meta tags. These components support the new runtime rendering and live-update capabilities.

lib/beacon/web/components · high confidence

The Beacon CMS core library is introduced, providing the foundational APIs for building websites with Phoenix LiveView. This includes the main \Beacon\ supervisor for managing site lifecycles, a \Beacon.Cache\ for stampede-safe ETS caching with TTL, and a \Beacon.CircuitBreaker\ to prevent cascading failures. The \Beacon.Content\ module handles content management for layouts, pages, and components, while \Beacon.MediaLibrary\ manages asset uploads and CDN delivery. Additionally, the \Beacon.Lifecycle\ system allows users to inject custom logic into the page loading and rendering process, and \Beacon.Config\ provides a registry for site-specific settings. The \Beacon.Migration\ module is also included to manage database schema updates.

lib/beacon · high confidence

The \native/beacon\_css\ module introduces a new native CSS compiler written in Zig. This update adds the core infrastructure for parsing and generating CSS, including a \Candidate\ parser, an \Emitter\ for building CSS output, and a \utilities\ map for static CSS properties (such as \display\, \flex\, \overflow\, and \position\). It also includes a \variants\ module that resolves pseudo-class and media query wrappers (like \hover:\, \sm:\, and \dark:\). The compiler currently supports static utility classes and variant application, with placeholders for functional utilities and theme resolution in future phases.

_native/beacon\css · high confidence

A new JavaScript file, assets/js/beacon.js, has been added to handle client-side updates for CSS paths and meta tags. This runtime listens for 'phx:beacon:page-updated' events to dynamically update the stylesheet and replace meta tags in the document head, and also manages the LiveSocket connection with user-defined hooks.

assets/js · high confidence

Added new processor modules for the media library: a default processor that handles basic metadata and binary reading, and an image processor that converts uploads to WebP, generates thumbnails, and creates 480px wide variants. These processors are now available for media upload workflows, enabling automatic format conversion and asset generation.

_lib/beacon/media\library/processors · medium confidence

The template processing pipeline has been refactored to use a new, platform-agnostic AST representation for templates. This change introduces a new \Beacon.Template.AST\ module that defines node types for elements, text, expressions, conditionals, loops, and fragments. A new \SourceParser\ handles the parsing of Beacon template syntax into this AST, while \ComponentExpander\ handles the expansion of component references. Additionally, a \HEExConverter\ is introduced to convert HEEx templates to the new syntax, and helper functions for date/time formatting are added to \Beacon.Template.Helpers\. This provides a more robust and flexible way to process and render templates.

lib/beacon/template · high confidence

Added new modules (Helper, Parser, TagHelper) that enable users to define and execute custom Elixir code blocks (snippets) within templates. This introduces a new \beacon\_snippet\_helpers\ schema and a corresponding Solid template tag (\{% helper %}\) to invoke these snippets, allowing for dynamic content generation in page fields.

lib/beacon/content/snippets · high confidence

The CSS engine now supports a three-tier storage system (in-memory ETS, optional S3 warm tier, and cold recompile) to improve performance and durability. A new \Beacon.CSS.Storage\ module handles fetching and storing compiled CSS, falling back to recompilation if S3 is not configured. Additionally, a \Beacon.CSS.ThemeParser\ was added to parse Tailwind v4 JavaScript config files, extracting theme values and splitting fontSize arrays into separate size and line-height variables for the compiler. A \Beacon.CSS.CandidateExtractor\ was also introduced to reliably extract CSS class candidates from templates.

lib/beacon/css · high confidence

The web module now includes dedicated modules for managing page assigns, HTTP caching, and generating site-wide files. A new \Beacon.Web.BeaconAssigns\ struct provides read-only access to current page information (site, path, query params) in templates and event handlers. A \Beacon.Web.Cache\ module handles HTTP cache headers and conditional requests. Additionally, \Beacon.Web.DataSource\ manages page titles and meta tags, while \Beacon.Web.RobotsTxt\ and \Beacon.Web.SitemapXML\ generate \robots.txt\ and \sitemap.xml\ files per site.

lib/beacon/web · high confidence

A new JavaScript file (beacon.js/beacon.min.js) is added to the static assets, implementing a client-side runtime that listens for CSS and page update events, manages the Phoenix socket connection, and merges user-defined hooks into the LiveView instance.

priv/static · high confidence

The PageLive component now handles live page rendering and subscribes to PubSub topics for page render updates, CSS compilation, and GraphQL cache invalidation. It supports three live update modes (manual, notify, automatic) and displays a customizable update notification banner when a page is updated, allowing users to refresh or dismiss the notification.

lib/beacon/web/live · medium confidence

The Beacon GraphQL module introduces a complete data layer for fetching and processing GraphQL data. The \QueryExecutor\ orchestrates page queries with dependency resolution and parallel execution, automatically unwrapping single-key responses. A \ResponseCache\ provides stampede-safe caching for queries. The \Client\ handles HTTP requests using a dedicated Finch pool and implements a circuit breaker to prevent cascading failures. Additionally, \TypeCoercion\ converts string parameters to appropriate types (Int, Float, Boolean, List) based on introspected schema, and \VariableResolver\ maps path, query, and prior-result variables into GraphQL query variables.

lib/beacon/graphql · high confidence

Added new Mix CLI tasks to streamline the setup of Beacon sites. \mix beacon.install\ bootstraps the core installation, while \mix beacon.gen.site\ generates new site endpoints with support for custom hosts and paths. Additional tasks include \mix beacon.gen.proxy\_endpoint\ for serving multiple domains, \mix beacon.gen.safelist\ for automatic Tailwind CSS class extraction, and \mix beacon.gen.tailwind\_config\ for Tailwind configuration. These tasks simplify the process of adding and configuring multiple sites within a Phoenix application.

lib/mix · high confidence

The content module now includes new Ecto schemas for managing URL redirects (Beacon.Content.Redirect), A/B testing page variants (Beacon.Content.PageVariant), and server-side event handling (Beacon.Content.EventHandler, Beacon.Content.InfoHandler). Users can now define custom redirects with regex support and circular-reference protection, create multiple template variants for pages with weighted randomization, and register Elixir code to handle LiveView events and background messages. Additionally, the diff introduces schemas for GraphQL endpoints (Beacon.Content.GraphQLEndpoint), JS hooks (Beacon.Content.JSHook), and content collections (Beacon.Content.Collection), expanding the platform's capabilities for dynamic content and external data integration.

lib/beacon/content · high confidence

The Beacon library introduces new lifecycle modules for assets, pages, and templates, enabling users to attach custom callbacks at specific points in the asset upload, page creation/update/publish/unpublish, and template loading/rendering processes. These hooks allow for extensibility, such as generating thumbnails for uploaded assets, triggering actions after page updates, or modifying template rendering behavior.

lib/beacon/lifecycle · high confidence

The framework now ships a pre-bundled Tailwind CSS configuration and a default stylesheet containing Phoenix alert styles, LiveView interaction classes (such as \.phx-loading\ and \.phx-modal\), and standard CSS animations (fade-in/fade-out). This change provides an immediate, styled baseline for Phoenix applications without requiring manual Tailwind setup.

priv · high confidence

The \BeaconWeb.DynamicLayoutView\ and \BeaconWeb.LayoutView\ modules have been removed. These views previously handled rendering of page titles, meta tags, and stylesheet links for dynamic layouts. Their removal indicates a shift away from the previous view-based layout system, likely in favor of a new layout or component-based approach.

_lib/beacon\web/views · high confidence

A new template for rendering runtime errors has been added to the application's layout system. This change introduces a dedicated HTML structure for error states, ensuring that when a runtime error occurs, the user is presented with a properly formatted error page that includes the necessary CSRF token, title, and references to the application's CSS and JavaScript assets via the Beacon.Web.Layouts module.

priv/layouts · high confidence

The library now supports Phoenix.HTML v4, enabling compatibility with the latest Phoenix web framework releases. Internally, the codebase has been restructured with the addition of new modules: \Beacon.Web\ provides a centralized setup for controllers, live views, and HTML helpers, while \Beacon.Content.Page.Helper\ introduces a new embedded schema for page-related data. Additionally, \Beacon.Web\ now includes validation to prevent overwriting reserved assigns like \:beacon\, and a suite of new error types (e.g., \Beacon.ConfigError\, \Beacon.LoaderError\, \Beacon.RuntimeError\) have been introduced to provide more specific error messages for configuration, loading, and runtime issues. The \Beacon.Heroicons\ module has also been added to handle SVG icon rendering.

lib · high confidence

The application now uses a centralized \config/config.exs\ to define core settings for Beacon (e.g., binary IDs), Phoenix (JSON library), and development-specific build tools like esbuild and Tailwind. A dedicated \config/test.exs\ is introduced to configure the test database, session handling, endpoint definitions for site\_a and site\_b, and mock AWS credentials for testing.

config · high confidence

The database schema is updated with new tables and columns to support a GraphQL data layer, site-wide settings, and a flexible template/collection system. Specifically, migrations introduce \beacon\_graphql\_endpoints\ and \beacon\_page\_queries\ to replace legacy data sources, add \beacon\_site\_settings\ for global configuration, and create \beacon\_collections\ to replace the previous \beacon\_template\_types\ and content-type-specific columns (like \page\_type\ and \faq\_items\) with a unified \fields\ map. Additional migrations add SEO metadata columns (e.g., \meta\_description\, \og\_title\), author and redirect tables, and an \ast\ column for pages, components, and layouts to support a platform-agnostic template AST system.

lib/beacon/migrations · high confidence

The system now uses a new \RuntimeRenderer\ module to load published content into an ETS store, replacing the previous BEAM module compilation pipeline. Pages are loaded lazily on first request rather than at boot, while the route index is loaded at startup to enable fast path matching. The \PubSubHandler\ has been updated to wire cascade invalidation into PubSub event handlers, ensuring that content updates trigger the appropriate ETS reloads and CSS recompilation without unloading dynamic modules.

_lib/beacon/runtime\renderer · high confidence

The Beacon actions system has been refactored to use a new declarative action interpreter that executes steps such as navigation, state management, and DOM manipulation via Phoenix LiveView. This replaces the previous DataStore and live\_data mechanisms with a structured, step-based execution model. Additionally, a new security module signs and verifies action documents using HMAC-SHA256 to prevent tampering, and a validator ensures action documents adhere to a strict schema. Finally, encrypted binary storage is introduced for the Beacon module, utilizing Cloak for data protection.

lib/beacon/actions, lib/beacon/encrypted · medium confidence

The codebase introduces four new Ecto type modules in lib/beacon/types: Site, Atom, Binary, and JsonArrayMap. The Site type enforces that site identifiers are valid atoms (with specific validation rules) and handles conversion between atoms and strings for database storage. The Atom type provides a generic atom type with casting and dumping logic. The Binary type handles term-to-binary conversions. The JsonArrayMap type enforces a data shape of a list of maps, supporting JSON string input/output. These types standardize how these data structures are validated and persisted within the application.

lib/beacon/types · high confidence

Added new Heex layout templates for the application, dynamic, and runtime views. The app layout provides a centered content wrapper, the dynamic layout includes a flash group and renders dynamic content, and the runtime layout defines the full HTML5 structure with head tags for SEO, meta information, title, resource links, and asset paths.

lib/beacon/web/components/layouts · medium confidence

The media library has been refactored to support external storage providers, starting with an S3 implementation. Assets are now represented by a new \Beacon.MediaLibrary.Asset\ schema and a \Beacon.MediaLibrary.Provider\ interface, allowing media to be stored in services like S3 rather than the database. The \UploadMetadata\ struct has been updated to handle the new provider configuration, and the \AssetField\ module now supports custom metadata fields for assets, enabling richer data management in the admin interface.

_lib/beacon/media\library · medium confidence

The custom plug responsible for setting the root layout to \BeaconWeb.LayoutView.root.html\ has been removed from the application. This change indicates a shift away from the previous plug-based approach for configuring the root layout, likely in favor of a different layout configuration mechanism.

_lib/beacon\web/plugs · high confidence

The dynamic module loading system for components, layouts, and pages has been removed. This eliminates the runtime generation and hot-reloading of Elixir modules for these resources, meaning the application will no longer support the previous mechanism for dynamically compiling and loading these templates at runtime.

lib/beacon/loader · high confidence

The \BeaconWeb\ module, which previously provided convenience macros for controllers, views, and LiveViews, has been removed. This change reflects a migration away from the traditional Phoenix view-based rendering in favor of the modern LiveView and component-based architecture, aligning with the upgrade to Phoenix 1.7 and LiveView 0.18.

_lib/beacon\web · high confidence

The \Beacon.Layouts.Layout\ Ecto schema has been removed from the codebase. This change eliminates the previous data model for layouts, which previously stored fields for \body\, \meta\_tags\, \stylesheets\, \title\, and \site\. Users relying on this specific schema structure will need to adapt to the new layout management approach introduced by the Lifecycle API and associated page/layout refactoring.

lib/beacon/layouts · medium confidence

The \BeaconWeb.PageLive\ module, which previously handled page rendering and data loading for the web interface, has been removed. This change eliminates the old LiveView implementation in favor of a new architecture for page rendering and data management.

_lib/beacon\web/live · high confidence

The \live\_data\ callback has been removed from the \Beacon.DataSource.Behaviour\ interface. This means that data source implementations no longer need to provide a \live\_data/3\ function, simplifying the contract for data sources that do not require live data updates.

_lib/beacon/data\source · high confidence

The database migration files for the \layouts\, \pages\, \components\, and \page\_versions\ tables have been deleted from the \priv/repo/migrations\ directory. This removes the initial schema definitions for these entities from the application's migration history.

priv/repo · high confidence

The legacy layout templates for the dynamic and root layouts have been removed. This change accompanies the upgrade to Phoenix 1.7 and LiveView 0.18, which utilize a different template structure (layouts and components) rather than the previous view-based approach. Users will no longer see the old HTML head and body structure defined in these specific template files, as the framework now handles layout rendering through the new conventions.

_lib/beacon\web/templates · high confidence

The legacy Ecto schema definitions for \Beacon.Components.Component\, \Beacon.Pages.Page\, and \Beacon.Pages.PageVersion\ have been removed from the codebase. This change eliminates the previous data models for managing pages and components, indicating a structural shift in how page content and component data are persisted or handled within the application.

lib/beacon/pages · high confidence

Beacon now requires LiveView 1.0.0 or higher. This upgrade brings significant changes to the LiveView API, including the removal of deprecated assigns like \@beacon\_live\_data\ in favor of spread top-level assigns, and updates to component attributes such as \dynamic\_tag\ using \:tag\_name\. Users must upgrade their LiveView dependency and update their templates to use the new assign patterns and component attributes.

(repo-wide) · high confidence

The project now includes explicit configuration files for code quality and formatting, specifically adding .eslintrc.js, .prettierrc.js, and .prettierignore to standardize JavaScript/HTML styling and linting rules. Additionally, Tailwind CSS is now fully configured via tailwind.config.js, which enables the forms and typography plugins and integrates custom variants for LiveView loading states, while the main stylesheet (beacon.css) is set up to import Tailwind's base, components, and utilities.

assets · medium confidence

The project has updated the bundled Heroicons library to version 2.0.16. This change replaces the previous icon set with the latest solid-style SVG icons, including updated paths and new additions, ensuring access to the most recent iconography from the Tailwind Labs library.

assets/vendor · high confidence

Add integration tests for PageLive; Add test support infrastructure for integration testing; Added comprehensive test coverage for core Beacon modules; Added placeholder test for Beacon Web components; Added test coverage for template parsing, rendering, and component expansion; Added test fixtures for Beacon content; Added test migration helper for Beacon tables; Added test support files for install task testing; Added tests for Beacon's new GraphQL data layer and action validation; Added tests for Beacon.Web components; Added tests for CSS candidate extraction, manifest validation, and storage operations; Added tests for SEO features; Added tests for asset and template lifecycle hooks; Added tests for content management features; Added tests for web controllers; Added unit tests for Beacon type modules; Expanded test suite with new test helpers and fixtures.

The project's frontend dependencies in \assets/package.json\ and \assets/package-lock.json\ are updated to include \tailwindcss\ v3.4, \@tailwindcss/forms\ v0.5, and \@tailwindcss/typography\ v0.5, alongside \prettier\ v3.2 as a dev dependency. On the backend, \mix.exs\ and \mix.lock\ are updated to require Elixir 1.14.1/1.15, Phoenix 1.7/1.8, and Phoenix LiveView 1.0.1+, while adding or updating dependencies such as \accent\, \cloak\_ecto\, \ex\_brotli\, \finch\, \oembed\, \req\, \req\_embed\, \safe\_code\, and \solid\. The \tailwind\_compiler\ dependency is pinned to a specific GitHub tag, and \esbuild\ is conditionally versioned based on the OTP release.

(dependencies) · medium confidence

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

• CAI 60 → 65 (+5.8)
• Rubric changed (rubric-2026.08.19 → rubric-2026.09.15) — scores are not directly comparable.

• Code Health 91 → 95 (+3.3)
• Architecture 96 → 92 (-3.4)
• Maturity 62 → 62 (-0.3)
• Readiness 49 → 57 (+8.5)
• Security 63 → 76 (+13.3)

• Change coupling: beacon_web.ex ↔ mix.exs (lib/beacon_web.ex)
• Change coupling: config.exs ↔ mix.exs (config/config.exs)
• Change coupling: core_components.ex ↔ mix.exs (lib/beacon/web/components/core_components.ex)
• Coverage not included — suite not readable by the collector
• Dependency hygiene not measured — dependency manifest found but not parsed for hygiene
• Duplicated block (10 lines × 2) (lib/beacon/proxy_endpoint.ex)
• Duplicated block (10 lines × 2) (lib/beacon/runtime_renderer.ex)
• Duplicated block (10 lines × 2) (lib/beacon/runtime_renderer.ex)
• Duplicated block (11 lines × 2) (lib/beacon/cache.ex)
• Duplicated block (11 lines × 2) (lib/beacon/migrations/v013.ex)
• Duplicated block (11 lines × 2) (lib/beacon/seo/index_now.ex)
• Duplicated block (12 lines × 2) (lib/beacon/runtime_renderer.ex)
• Duplicated block (14 lines × 2) (lib/beacon/runtime_renderer.ex)
• Duplicated block (14 lines × 2) (lib/beacon/runtime_renderer/loader.ex)
• Duplicated block (17 lines × 2) (lib/beacon/runtime_renderer.ex)
• Duplicated block (17 lines × 3) (lib/beacon/content.ex)
• Duplicated block (23 lines × 2) (lib/beacon/content.ex)
• Duplicated block (5 lines × 3) (lib/heroicons.ex)
• Duplicated block (6 lines × 2) (lib/beacon/content.ex)
• Duplicated block (6 lines × 2) (lib/beacon/content.ex)
• …and 53 more

• Change-coupling hub: mix.exs → config.exs, core_components.ex, beacon_web.ex (mix.exs)
• Documentation: no usage examples (README.md)
• Duplicated block (10 lines × 2) (lib/beacon/content/component_attr.ex)
• Duplicated block (10 lines × 2) (lib/beacon/content/page_field.ex)
• Duplicated block (10 lines × 2) (lib/beacon/runtime_renderer.ex)
• Duplicated block (10 lines × 2) (lib/beacon/runtime_renderer.ex)
• Duplicated block (10 lines × 2) (lib/beacon/runtime_renderer.ex)
• Duplicated block (10 lines × 35) (lib/heroicons.ex)
• Duplicated block (11 lines × 2) (lib/beacon/migrations/v013.ex)
• Duplicated block (11 lines × 2) (lib/beacon/seo/index_now.ex)
• Duplicated block (12–13 lines × 2) (lib/beacon/proxy_endpoint.ex)
• Duplicated block (12–14 lines × 2) (lib/beacon/cache.ex)
• Duplicated block (14 lines × 3) (lib/beacon/runtime_renderer/loader.ex)
• Duplicated block (15 lines × 2) (lib/beacon/content/page_field.ex)
• Duplicated block (16 lines × 2) (lib/beacon/runtime_renderer.ex)
• Duplicated block (16 lines × 3) (lib/beacon/content.ex)
• Duplicated block (17–21 lines × 2) (lib/beacon/content.ex)
• Duplicated block (20 lines × 2) (lib/beacon/runtime_renderer.ex)
• Duplicated block (22 lines × 2) (lib/beacon/content.ex)
• Duplicated block (22 lines × 2) (lib/beacon/content/page_field.ex)
• …and 139 more

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

BeaconCMS/beacon was measured the same way every project in this corpus was: the same rubric, at a pinned commit, with the result published in full. Point a surveyor at a repository you know and see whether you agree with it.