guest@czt.sh~/projects/publisher
Publisher: one web platform for every site
The shared enterprise web platform behind every Isolated Command site — build the platform once, let every site inherit the result.
The shared foundation behind every Isolated Command site
Publisher is the proprietary enterprise web platform developed and maintained by the Research and Development (R&D) Team. It is the single foundation on which Isolated Command builds its public websites and internal applications.
Rather than every team starting from an empty repository — re-implementing navigation, branding, accessibility, security and delivery each time — Publisher provides all of that as a governed, shared platform. Individual sites become thin: they contribute their content, configuration and brand assets, and inherit a complete, production-ready experience.
Build the platform once. Improve it continuously. Let every site inherit the result.
Why Publisher exists
Before Publisher, each Isolated Command property was its own codebase. That created predictable problems:
- Drift. Sites slowly diverged in look, behaviour and quality.
- Duplicated effort. The same header, footer, and components were rebuilt repeatedly.
- Inconsistent standards. Accessibility, performance and security were applied unevenly.
- Slow propagation. A fix or improvement had to be re-applied to every site by hand.
Publisher exists to make the right thing the easy thing. Standards live in one place, improvements roll out everywhere, and teams spend their time on what makes their site distinct rather than on boilerplate.
What Publisher is not: it is not a public general-purpose CMS, not a runtime application server, and not a per-site fork — sites consume the platform as a versioned dependency.
The platform at a glance
Publisher is organised into four cooperating layers, each with a single, clear responsibility:
- Sources — the content, configuration and brand assets owned by each site.
- The shared theme — layouts, components, styling and behaviour, consumed as a versioned Hugo Module, never copied.
- The build pipeline — a deterministic process that renders sources into pre-built HTML with optimised, fingerprinted assets.
- Delivery — static assets served from Cloudflare’s edge network; no application server to run, scale, or attack.
The design is strictly one-directional: sites depend on the theme, never the reverse; configuration flows into components; improvements flow outward from the platform to every site on its next build. That is what keeps a growing network of sites coherent.
Core features
| Capability | Benefit |
|---|---|
| Shared component library | Consistency by default — headers, footers, navigation, cards, callouts, tabs defined once |
| Configuration-driven sites | Launch or rebrand without touching a template — menus, branding, CTAs, role-gated items all in config |
| Centralized updates | Fix once, ship everywhere — sites pull the latest platform on every build |
| Deterministic static output | Speed, scale, predictability — same inputs, same output, every time |
| Built-in quality standards | Accessibility, performance and SEO baked into the shared components |
| Multi-format rendering | The same content emits HTML plus machine-readable and plain-text variants |
| Extension slots | Bespoke needs (navbar slots, custom home layouts) without forking the platform |
Security model
Publisher’s strongest security property comes from its architecture: there is no application server running at request time. Public sites are pre-rendered static assets, which removes entire classes of vulnerability — server-side injection, runtime dependency exploits and request-time data leaks have no surface to attack.
- Zero-trust for protected applications — identity verified at the edge before content is served; least-privilege roles; hidden UI treated as defence-in-depth, never as the security boundary.
- Reviewed, auditable change — all changes flow through version control and review; every deploy is an immutable, attributable artefact.
- Secrets stay out of repos — supplied through environment configuration, scoped to the minimum required.
The stack — boring in the best way
| Layer | Technology role | Why |
|---|---|---|
| Authoring | Markdown + front matter | Simple, durable, tool-friendly |
| Composition | Hugo (static site generator) | Deterministic rendering, components |
| Distribution | Versioned Hugo Module | Central updates, no forks |
| Styling | Compiled SCSS bundle | Consistency, lean payloads |
| Build/Deploy | Automated pipeline | Repeatable, atomic releases, instant rollback |
| Delivery | Cloudflare edge (static) | Speed, resilience, low cost |
| Access | Cloudflare Zero Trust | Secure protected apps |
Each layer is independently understood, replaceable and well-documented. A platform that many teams rely on should be predictable first.
Roadmap
Publisher evolves continuously rather than in big-bang releases — every site pulls the latest compatible platform on each build.
| Stage | Focus |
|---|---|
| Shipped | Module platform, config-driven navigation, role-gated menus, extension slots, deterministic static builds, atomic deploys with rollback |
| In progress | Component documentation, accessibility hardening, performance budgets |
| Planned | Design tokens, content model templates, build insights, expanded output formats |
Every roadmap item is weighed against the platform’s design principles: does it keep sites consistent by default, can it ship as configuration, is it backwards compatible, and does it respect the performance and accessibility baseline?
Powered by Publisher
Publisher is the foundation under the whole Isolated Command family: isolatedcommand.com, Go (URL shortener), File (secure file transfer), the Volunteer Management System, and the IC Directory.