Astra vs Blocksy vs Brndle: Customizer Controls, Container Layouts, or Tailwind Tokens

Every WordPress theme comparison eventually turns into a feature checklist: does it have a header builder, how many color presets, is there a pattern library. Those checklists miss the question that actually determines how a build ages: where does the design system live, and who (or what) can change it? Astra, Blocksy, and Brndle, the free theme this site maintains, answer that question three structurally different ways. Astra puts it in the WordPress Customizer, nested panels you click through one at a time. Blocksy puts it in a visual, container-based header and footer builder shipped through its Companion plugin. Brndle puts it behind a REST API endpoint backed by Tailwind v4 tokens and theme.json, readable and writable as JSON, not just clickable in an admin screen.

This matters more than it sounds like it should, because the answer changes who can touch the design system and how. A Customizer panel is built for a human with a mouse. A REST endpoint is built for a human with a mouse or a script, a CI pipeline, a WP-CLI command, or another piece of software entirely. Neither is objectively better, they are built for different jobs, and this comparison is about being honest about which job each one does well. Real current pricing (checked 30 October 2026, linked below so you can re-check it), real code pulled from each project’s own source where it is public, and a worked scenario for the decision that actually matters: an agency standardizing a brand across twenty client sites.

In this comparison

• Why architecture, not feature count, is the real comparison
• Astra: the WordPress Customizer, nested panels and all
• Blocksy: containers, the header builder, and the Companion plugin
• Brndle: Tailwind tokens behind a REST endpoint
• Side by side: where each control panel lives, and what it costs
• A worked scenario: an agency rebranding 20 client sites
• The bottom line
• Questions about Astra, Blocksy and Brndle
• What should you do next?

Why architecture, not feature count, is the real comparison

Ask “which theme has more design options” and all three hold up fine against each other: global colors, typography pairs, header and footer layout controls, spacing scales. That question flatters feature lists and hides the part that actually costs an agency money six months into a contract, which is where those options are stored and how you change them at scale. A setting that only exists as a value typed into a Customizer field is a setting you can only change by opening that Customizer field, on that site, by hand. A setting exposed through a REST endpoint is a setting you can read, diff, version, and push to twenty sites with one script.

The three themes in this comparison sit at three different points on that spectrum, and none of them got there by accident. Astra’s Customizer-first architecture is a direct descendant of the WordPress theme ecosystem’s oldest convention, the Customizer API has been the standard integration point for theme options since WordPress 3.4 in 2012, and Astra built a sprawling, deeply nested version of it because that is what most WordPress users and agencies already know how to drive. Blocksy modernized the same basic idea: instead of dozens of flat Customizer sections, it ships a visual, drag-and-drop builder for the parts of a site people rebuild most often, the header and footer, while keeping the rest of its settings in Customizer-adjacent panels. Brndle, built on Sage and Acorn with Laravel’s Blade templating and Tailwind CSS v4, skipped the Customizer almost entirely and put its settings behind a REST API from day one, because the team building it was already thinking in tokens and components, not Customizer sections.

Being fair about the tradeoff up front: a REST-first, code-friendly design system is not automatically the right answer. It is the right answer for a developer or an agency that wants to script, diff, and replicate configuration across sites. It is very often the wrong answer for a solo site owner or a client’s in-house marketing person who wants to click a color swatch and see the header change, with no JSON, no endpoint, no build step in sight. Keep that split in mind through the rest of this post, because it is the actual decision, not which theme has the longer feature list.

Astra: the WordPress Customizer, nested panels and all

Astra’s free theme, over 1 million active installs, is built entirely around the native WordPress Customizer (Appearance → Customize). Every design decision, global colors, container width, header layout, typography, button styling, lives inside a tree of Customizer panels and sections, each one a step deeper than the last. Changing the primary header’s background color is not one click, it is Customizing › Layout › Header Builder › Primary Header › Colors and Background › Background Color, a path five levels deep before you even reach the color picker. Astra’s own product walkthrough shows exactly this nesting:

That depth is not a flaw, it is the Customizer’s whole design contract: every change previews live against the real site before you publish, and the hierarchy exists so a non-technical user never has to see a setting that is not relevant to what they are currently editing. For a site owner who wants to see their header change color in real time without touching code, this is the single most familiar interface in the entire WordPress ecosystem. Every WordPress user who has built a site since 2014 has seen this panel in some form, on some theme. There is zero onboarding cost for a client who already knows WordPress.

The cost shows up the moment you need to replicate a configuration across more than one site. The Customizer stores its values as individual theme_mod entries in the WordPress options table, there is no single exportable settings object by default, and no REST endpoint ships with the free theme for reading or writing those values programmatically. Astra Pro adds a Starter Templates import flow that can bring in a full page or site design, but that is importing a pre-built template, not exporting your own live configuration from Site A and pushing it to Sites B through T. Replicating a Customizer-driven brand update across many sites in practice means one of three things: clicking through the same panel tree on every site by hand, using a third-party Customizer-sync plugin as an extra dependency, or scripting raw wp option update theme_mods_astra calls against WordPress’s internal serialized PHP array format, which is exactly the kind of fragile, undocumented surface a REST endpoint exists to avoid.

Pricing has consolidated into bundles, the same pattern GeneratePress and Kadence have both followed. As of this check, Astra no longer sells a standalone Astra Pro license at its headline price, it sells Astra Pro + AI at three tiers:

• Astra Pro + AI: $99/year intro (renews at $149/year), 1 hosted website plus a free first-year domain, aimed at solo builders working on personal or a few small client projects.
• Essential Toolkit + AI: $199/year intro (renews at $299/year), 2 hosted websites, aimed at freelancers managing multiple client sites, and bundling Spectra Pro, Premium Starter Templates, Ultimate Elementor Addons and SureForms Agency alongside Astra Pro itself.
• Business Toolkit + AI: $279/year intro (renews at $429/year), 5 hosted websites, aimed at agencies managing a large number of client sites, same bundle at a higher site allowance.

Every tier is an introductory rate; Astra’s own pricing page states renewals bill at the full, higher rate shown above, not the discounted first-year price. Note the “hosted websites” language too, several tiers bundle a limited number of actual hosting slots on Astra’s own infrastructure alongside the license, which is a different thing than “number of sites the license key activates on.” Read the fine print on your tier before assuming it covers twenty client domains you host yourself.

Blocksy: containers, the header builder, and the Companion plugin

Blocksy takes a visibly more modern approach to the same basic problem without leaving the Customizer-adjacent model entirely. Most of its settings still live in Customizer-style panels, but the part of the theme people touch most, the header and footer, is built as a dedicated drag-and-drop builder shipped through the free Blocksy Companion plugin. Instead of a flat list of “show logo / hide logo” toggles, Blocksy models the header as a set of containers, horizontal zones (top bar, main row, a transparent or sticky variant) that each hold draggable elements: Logo, Menu, Search, Cart, Trigger, Socials, Text, raw HTML. You drag an element out of a tray and drop it into a container, and the layout updates live. Blocksy’s own marketing material shows the mechanic directly:

This is a genuine step up from a flat Customizer tree for the specific job of building a header: it is spatial, it is visual, and it maps closely to how a designer would actually sketch a header on a whiteboard, as boxes and rows rather than a settings list. It is also still fundamentally a UI-driven configuration surface. The container layout is stored as plugin settings (again, individual options in the database rather than a single documented, exportable object), configured by dragging elements in the browser, one site at a time. Blocksy Companion does ship a site-export feature for moving a configured demo between sites, which is a real convenience for an agency reusing the same starting point, but it is a one-time template import, not an ongoing, scriptable sync between a canonical source of truth and many live sites. If you update the container layout on your reference site next quarter, that change does not propagate anywhere until someone re-exports and re-imports it by hand on every other site.

Blocksy’s pricing structure is simpler than Astra’s or Spectra’s bundle-everything approach, it sells its own Pro plugin directly rather than folding in unrelated products:

• Personal: $69/year (or $199 one-time lifetime), use on 1 site.
• Professional: $99/year (or $299 one-time lifetime), use on 10 sites.
• Agency: $149/year (or $499 one-time lifetime), unlimited sites.

For an agency specifically, Blocksy’s Agency tier is the most straightforward of the three paid options compared here: one flat $149/year for unlimited sites, no per-site counting, no unrelated bundled products. The honest tradeoff is that “unlimited sites” licenses you to use Blocksy Pro everywhere, it does not give you a mechanism to push one container-builder configuration to all of them at once. Each site’s header still gets built, or re-built, in that site’s own Companion panel.

Brndle: Tailwind tokens behind a REST endpoint

Brndle’s settings architecture does not start from the Customizer at all. The theme registers a single top-level admin menu item, positioned deliberately “after Comments (25), before Appearance (60)” per the source comment, and the page it renders is one line of markup:

public function renderAdminPage(): void
{
    echo '<div id="brndle-settings-root"></div>';
}

A React admin app mounts into that div and talks to a REST API registered under the brndle/v1 namespace, not the Customizer’s theme_mod system. The route list, pulled directly from the theme’s SettingsServiceProvider:

register_rest_route($namespace, '/settings', [
    [ 'methods' => 'GET',    'callback' => [$this, 'handleGetSettings'] ],
    [ 'methods' => 'POST',   'callback' => [$this, 'handleSaveSettings'] ],
    [ 'methods' => 'DELETE', 'callback' => [$this, 'handleResetSettings'] ],
]);

register_rest_route($namespace, '/settings/export', [ 'methods' => 'GET',  'callback' => [$this, 'handleExportSettings'] ]);
register_rest_route($namespace, '/settings/import', [ 'methods' => 'POST', 'callback' => [$this, 'handleImportSettings'] ]);
register_rest_route($namespace, '/cache/purge',     [ 'methods' => 'POST', 'callback' => [$this, 'handlePurgeCache'] ]);

Every one of those routes is gated behind current_user_can('manage_options'), the same capability check a Customizer screen uses, so this is not a lower-security surface than Astra or Blocksy’s panels, it is the same permission model exposed as JSON instead of only as HTML form fields. The practical difference: GET /wp-json/brndle/v1/settings returns the entire design system, color scheme, font pair, header and footer style, performance flags, as one JSON object. POST the same shape back (or a partial object, the handler merges it with existing values) and the live site updates, with no browser involved at all. That means a WP-CLI command, a deploy script, or a CI job can read a canonical settings file out of version control and push it to any number of sites in a loop, the exact workflow a Customizer-only or Companion-plugin-only theme cannot support without reverse-engineering an undocumented options schema.

The token system underneath is Tailwind v4, compiled through Vite 7, with the theme’s color and font choices expressed as theme.json presets and CSS custom properties rather than inline styles scattered through templates. Brndle ships 12 built-in color schemes (Sapphire, Indigo, Cobalt, Trust, Commerce, Signal, Coral, Aubergine, Midnight, Stone, Carbon, Neutral) and 8 font pairs (System UI, Inter, Geist Sans, IBM Plex, DM Sans, Editorial, Magazine, Humanist) as the starting palette, all adjustable through the same settings object, and all extendable through documented WordPress filters rather than by editing theme files directly:

add_filter('brndle/color_presets', function (array $presets): array {
    $presets['brand'] = [
        'label'     => 'My Brand',
        'primary'   => '#FF6B00',
        'secondary' => '#1A1A2E',
    ];
    return $presets;
});

That filter and the REST endpoint are not two competing systems, the admin UI, the filters, and the REST API all read and write through the same central Settings::all() accessor, so a value changed through any one of the three paths is instantly visible through the other two. We cover how all twelve schemes hold up under actual WCAG contrast math, not just how they look, in a separate audit of the color system; this post is about where the configuration lives, not whether the defaults are accessible.

The honest limits of this approach, stated plainly: there is no live-preview pane the way the Customizer has one. Changing a setting through the admin screen saves and re-renders the page, it does not show a draft state you can discard before publishing the way Customizer or Blocksy’s builder do. And comfort with JSON payloads and REST calls is a real prerequisite for anyone who wants to go past the included admin screen, a client’s in-house marketing hire with no developer background can absolutely use the settings page’s color and font pickers, but scripting a bulk rollout across client sites assumes someone on the team is comfortable with curl, WP-CLI, or a small Node/PHP script. Brndle itself is 100% free, GPL-2.0-or-later, no license key, no paid tier at any size, which removes licensing cost from the “twenty sites” scenario entirely, but it does not remove the developer-comfort requirement the REST-first architecture assumes.

Side by side: where each control panel lives, and what it costs

	Astra	Blocksy	Brndle
Where settings live	WordPress Customizer, nested panels, theme_mod options	Customizer-adjacent panels, plus a visual container/element builder (Blocksy Companion) for header and footer	REST API (brndle/v1/settings) backed by theme.json and Tailwind v4 tokens, surfaced through a React admin screen
Primary interaction model	Click through 3–5 nested panels per setting, live preview pane	Drag elements into container zones, live preview in the builder canvas	Pick from a settings screen, or read/write the same data as JSON via REST, WP-CLI, or a script
Bulk/multi-site replication	No built-in export; manual per-site clicking or raw wp option update against serialized PHP	One-time site export/import for a starting template; no ongoing sync between sites	Native /settings/export and /settings/import REST routes; scriptable across any number of sites
Non-developer accessibility	Highest – the most familiar interface in the WordPress ecosystem, zero onboarding for an existing WP user	High – visual and spatial, easy for a designer or client to grasp without code	Moderate for the admin screen itself, low for anything beyond it without developer help
Design tokens	Global color/typography options stored as individual Customizer settings	Global colors/typography plus per-container layout settings	12 color schemes, 8 font pairs, expressed as theme.json presets and CSS variables, extendable via brndle/color_presets and brndle/font_pairs filters
Current pricing (checked 30 Oct 2026)	Astra Pro + AI $99/yr intro (renews $149/yr, 1 site) to Business Toolkit + AI $279/yr intro (renews $429/yr, 5 sites); all bundle Spectra Pro and other add-ons above the entry tier	Personal $69/yr (1 site) to Agency $149/yr (unlimited sites); sold standalone, not bundled with unrelated products	100% free, GPL-2.0-or-later, no license key, no paid tier at any size

A worked scenario: an agency rebranding 20 client sites

Say an agency runs twenty client sites on the same theme, standardized for maintenance reasons, and one client’s design refresh means updating a shared starter palette, say, shifting a default accent color and swapping a font pairing, across every site that still uses the agency’s house defaults rather than a fully custom brand.

1. On Astra, this is twenty separate trips through Customizing › Global › Colors and Customizing › Global › Typography, by hand, on every site, unless the agency invests in a third-party Customizer-sync tool or has a developer comfortable scripting raw wp option writes against Astra’s serialized settings format, which is unsupported and breaks silently if Astra changes its internal option structure in a future update. The Customizer’s live-preview pane is genuinely useful here, each change gets a visual check before publishing, but that benefit is purchased at the cost of twenty manual passes.
2. On Blocksy, the global color and font change is the same kind of manual, per-site process as Astra for anything outside the header/footer builder. If the rebrand also touches header layout, the agency could configure the new container arrangement once on a reference site, export it through Companion’s site-export feature, and import that starting point onto new builds going forward, but existing live sites each still need the new configuration applied by hand or via that same import flow, one at a time, and any subsequent tweak means repeating the export/import cycle again.
3. On Brndle, the agency keeps one canonical settings JSON file in version control, updates the primary color and font-pair keys in that file, and loops a script over all twenty site URLs: POST /wp-json/brndle/v1/settings with the updated JSON body and an authenticated request, once per site. No panel clicking, no export/import cycle repeated by hand, and the change is diffable in git before it ever touches a live site. The tradeoff: building that loop script assumes a developer on the team who’s comfortable with authenticated REST calls, which is exactly the kind of work a WordPress agency’s technical lead does routinely, but is a real step beyond what a Customizer or Companion-plugin workflow requires of anyone.

None of these is the wrong answer in isolation, they are three different bets on who does the rebrand work and how often it happens. An agency that rebrands rarely and values a client-facing, click-and-preview experience for the occasional one-off change gets real value from Astra’s or Blocksy’s UI-first model. An agency that standardizes dozens of sites on one house design system and expects to push updates to all of them repeatedly gets real, compounding value from a REST-scriptable architecture, the kind of value that is invisible on site one and decisive by site twenty.

The bottom line

Astra’s Customizer-first architecture is not outdated, it is the single most battle-tested, most familiar configuration surface in the WordPress ecosystem, and that familiarity has real value for any build where a client, not a developer, will be the one adjusting settings after launch. What it costs you is scale: nothing about the free theme or Astra Pro + AI’s bundled tiers gives an agency a documented way to replicate a configuration across many sites without manual, panel-by-panel work. Blocksy’s container-based header builder is a genuine, well-executed modernization of the same UI-first idea, more spatial and visual than a flat Customizer tree, and its flat per-site pricing (especially the $149/year unlimited-site Agency tier) is the most straightforward of the three paid options here. It inherits the same per-site, click-to-configure limitation as Astra for anything beyond a one-time template export.

Brndle cannot offer either competitor’s install base, years of refinement, or a live Customizer-style preview pane, and pretending otherwise would undercut the honest comparison this post is trying to make. What it offers instead, free, with no license key and no paid tier to unlock it, is a design system expressed as data: readable and writable as JSON through a documented REST API, extendable through WordPress filters, and scriptable across any number of sites by anyone comfortable with an authenticated HTTP request. If the deciding question for your next build is “how many client sites will someone need to update this on, and how often,” that question, not the size of either theme’s settings panel, is the one worth answering before you standardize.

Questions about Astra, Blocksy and Brndle

Does Brndle have a REST API because it’s trying to compete on raw feature count with Astra or Blocksy?

No, and it would lose that comparison if it tried. Astra and Blocksy both have years of UI refinement, larger install bases, and dedicated support teams Brndle doesn’t have. The REST endpoint exists because the theme’s own settings UI is built as a React app that needs an API to talk to, and exposing that same API for external, authenticated use was a small additional step once it existed. It’s an architectural byproduct of how the admin screen is built, not a headline feature competing for the same checklist slot as a header builder.

Can I export my settings from Astra or Blocksy the way I can from Brndle?

Partially, and differently. Astra Pro’s Starter Templates feature imports a pre-built page or site design, it isn’t built to export your own live Customizer configuration for replication elsewhere. Blocksy Companion has a site-export feature aimed at carrying a configured starting point (including header/footer layout) into new builds, which is closer to what you’d want, but it’s a one-time template transfer rather than an ongoing, scriptable sync with a documented data format. Neither ships a stable, public JSON schema for their settings the way Brndle’s /settings/export and /settings/import routes do.

Is the WordPress Customizer being deprecated in favor of the Site Editor?

For block themes, yes, broadly, WordPress’s own direction has moved toward the Site Editor (Full Site Editing) and theme.json for themes built that way. Astra and Blocksy are both classic (non-block) themes at their core, even though both now register some blocks and support newer editor features, so the Customizer remains their primary settings surface and isn’t going away for either on any announced timeline. Brndle, built as a hybrid that leans on theme.json and compiled Tailwind tokens rather than the Customizer, is closer to where block-theme architecture is headed, though it is not a pure FSE block theme itself.

Do I need to know Tailwind CSS to use Brndle’s settings page?

No. The settings page itself is point-and-click, choose a color scheme, a font pair, a header style, the same way you would in any other theme’s options panel. Tailwind is the compilation layer underneath those choices, it’s what turns a selected token into the CSS actually shipped to the browser. You only need to touch Tailwind directly if you’re writing custom Blade views or extending the design system beyond what the settings screen and filter hooks expose.

Which of the three is fastest to configure for a single, one-off client site?

Blocksy’s visual container builder is arguably the fastest for header/footer work specifically, since dragging elements into zones is quicker than clicking through five nested Customizer panels for the equivalent change. For global colors and typography, all three are comparably fast for a single site, pick a preset, see it apply. The speed difference between the three only shows up once you’re repeating the same configuration across more than one site.

Does a REST-based settings system mean Brndle is less secure than a Customizer-based theme?

No. Every Brndle settings route is gated behind WordPress’s own current_user_can('manage_options') capability check, the identical permission model a Customizer screen relies on. A REST endpoint is a different transport for the same authenticated, capability-checked write, not an unauthenticated side door. The same WordPress nonce and cookie-based authentication that protects wp-admin protects these routes.

Can I use Blocksy’s container-based header builder on Astra, or Brndle’s REST settings on Blocksy?

No to both. Each of these is built into its respective theme’s own codebase and isn’t published as a portable, theme-agnostic plugin. Blocksy’s header builder ships through the Blocksy Companion plugin, which is tied to Blocksy itself; Brndle’s settings REST API is registered by the Brndle theme’s own service provider. Switching themes means rebuilding the configuration in whichever system the new theme provides, the same limitation true of nearly every theme-native settings architecture.

What happens to my site’s design if I deactivate the respective companion plugin or theme?

For Blocksy, deactivating the Blocksy Companion plugin disables the header/footer builder and several other Pro features, though the base Blocksy theme continues to function with its remaining Customizer settings intact. For Astra, Astra Pro is a separate plugin from the free Astra theme; deactivating it removes the Pro-only Customizer sections but the free theme’s core settings remain. Brndle has no separate companion plugin, the REST API, settings page, and block library are all part of the single theme package, so there’s no equivalent “deactivate the companion” scenario to plan around.

Is there a performance difference between a Customizer-driven theme and a REST/token-driven one?

Not meaningfully from the configuration architecture itself, in all three cases the end result is CSS shipped to the visitor’s browser, and how that CSS got generated (Customizer-driven inline styles, Companion plugin CSS, or Tailwind-compiled utility classes from tokens) is a build-time or render-time concern separate from the admin experience. Real performance differences between these three themes would come from template rendering approach, asset bundling, and caching strategy, not from whether settings live in a Customizer panel or a REST endpoint.

If I’m not an agency managing multiple sites, does any of this architecture discussion matter to me?

Less, but not zero. A single-site owner benefits most from whichever interface feels most comfortable to them personally, which for most non-developers will be Astra’s or Blocksy’s UI-first approach. Where it can still matter on one site: if you ever want to back up your exact design configuration outside of a full site backup, migrate it to a staging environment for testing, or hand a precise specification to a developer without screen-sharing a Customizer session, a REST-exportable settings object is a genuinely easier artifact to work with than a serialized Customizer options blob.

What should you do next?

Check current pricing and architecture details yourself before standardizing an agency stack on any of these three, bundle structures and tier limits change often enough that parts of this post will need a re-check within months: Astra pricing, Blocksy pricing, and Brndle’s source on GitHub. If you’re specifically evaluating Brndle’s REST-based settings for a multi-site agency rollout, our piece on building a design system an AI agent can follow covers the same theme.json tokens and filter hooks referenced here in more depth, and our Kadence Blocks vs Spectra vs Brndle comparison is the companion read if you’re deciding on the block library layered on top of whichever theme’s settings architecture you choose underneath.