Blowhorn site and downloads

This repository is two things for Layer5 Blowhorn:

1. The marketing site at blowhorn.ai. It is a Hugo site with Docsy as a Hugo module, built like docs.layer5.io and deployed to GitHub Pages by site.yml. The Pages custom domain is already blowhorn.ai, so the project URL https://layer5io.github.io/blowhorn-site/ only redirects there; the site is reachable once the domain's DNS points at Pages, as docs/deploy.md describes.
2. Public downloads. macOS disk images and their checksums are published as GitHub Releases on this repository. No release binary is committed here.

Blowhorn is a social media console that takes one message and broadcasts, reposts and amplifies it across every profile and platform your community runs, on autopilot. One message out, many ears in.

Download

Download the current universal macOS build from blowhorn.ai/download. (This repository also publishes blowhorn-axi releases, so GitHub's latest is not reliably the desktop release and no always-latest asset link is offered here.)

Every release carries a SHA256SUMS.txt. Check the image before you open it:

shasum -a 256 -c SHA256SUMS.txt

The Chrome extension ships through the Chrome Web Store, not from this repository.

Where things live

Site configuration	hugo.toml; the pinned toolchain is go.mod (Docsy as a Hugo module), package.json (Hugo extended, postcss) and .nvmrc (Node.js)
Pages	content/en/: the home page's front matter, the Trust Center and its privacy and terms pages (legal/), the onboarding pages and short redirect paths at the root (welcome.md, signup.md, ...), and the docs/ section scaffold (landing, quadrant, group, and CLI indexes) in Markdown
Templates	layouts/: the home page (home.html), the shared shell (baseof.html), the Trust Center hub (trust-center.html), the legal pages (legal.html), the onboarding pages (onboarding.html), the redirect pages (redirect.html), the 404 page, the header, footer and icon sprite partials, the llms.txt and Markdown outputs, and the Docsy-based docs shell (layouts/docs/)
Styles and script	assets/css/site.css and assets/js/download.js (the /download/ page); Hugo minifies and fingerprints both. The docs section's Blowhorn skin over Docsy is assets/scss/, with its sidebar toggle and offline search in assets/js/
Brand assets	static/assets/brand/, served at /assets/brand/: version 1 of the brand kit (logo system, Major Blowhorn, marketing art, tokens.json) and the three self-hosted fonts; attribution in LICENSES.md
How the site deploys and how the domain is wired	docs/deploy.md
How releases are published	docs/distribution.md
Release binaries	Releases on this repository
Product source and build pipeline	Private: blowhorn

Reporting problems. The product repository is private, so use this repository's issues for everything public: site content, a download that will not open, a wrong checksum, or a bug in the app. Maintainers triage app bugs into the product repository. The Layer5 Slack works too.

Working on the site

You need Go (Hugo modules), Node.js and npm (the pinned Hugo extended and postcss come from package.json), Python 3 and make. The build targets mirror the blowhorn repository's website targets; the layer5io/docs names (build-production, build-internal, preview-internal) are kept as aliases. make help lists every target.

make setup             # npm install: the pinned Hugo extended and postcss
make site              # serve at http://localhost:1313 with live reload
make serve             # serve once, without live reload
make build             # local build with draft, future and expired content
make site-build        # public production build into public/, what CI deploys
make site-internal-build # internal build into public-internal/ (needs ../blowhorn)
make check             # every check, against a fresh production build
make ci                # exactly what site.yml's check job runs, starting with npm ci

Every CI step that runs repository logic is a make target, and the workflow calls that target, so one make command reproduces any CI step:

Target	What it runs	Run by
setup-ci	npm ci (the locked dependencies)	site.yml
workflow-check	actionlint on site.yml, publish-dmg.yml, sync-docs.yml, cloud-auth-smoke.yml and product-ci.yml	site.yml
test-scripts	unit tests for the check scripts in .github/scripts/	site.yml
site-check	one production build, then the checks below	site.yml
check-schemas	data/hero.json, data/roles.json, data/use_cases.json, data/themes.json, data/integrations.json, data/hero_demo.json, data/actions.json and data/action_examples.json validate against schemas/; role and use-case schemas $ref shared line/text/card types in schemas/defs/cast-page.schema.json (ajv -r) (docs/hero-variants.md). Every supported YAML action must have an example (docs/action-examples.md). Every action group in data/actions.json exists and holds an action (check_action_matrix.py --source)	site-check
check-theme	/ uses data/themes.json default plus content/en/_index.md front matter (Signal). /home-reveille/ keeps today's look. Counts in data-count-* spans match supported YAML actions. ?theme= swaps tokens only, not layout. Fails a new theme-specific content file outside the approved content/en/home-reveille.md	site-check
check-platform-docs	Every supported platform has a docs page that renders the shared supported-actions table from YAML. Fails a missing page, a page that skips the shortcode, or a docs page that still carries a hand-written action list or Action / What it does table	site-check
check-action-matrix	The site action matrix (/integrations/actions/) and the docs all-actions table (/docs/reference/platforms/actions/, shortcode all-actions) hold exactly the cells data/actions.json plus data/platforms/*.yaml give, in order, with the right link. Status is shown by exception: fails a rendered "supported" label or check mark, a coming-soon column without its clock, or an exception label that drifts from data/integrations.json matrix.exceptions. Fails a dead page or #action-<id> anchor, a hand-written table, or a lost link from / or /integrations/	site-check
validate-html	html-validate on every built page	site-check
check-links	every local link, image, font and srcset reference resolves	site-check
check-third-party	no page, or stylesheet or script it loads, requests another host (except the disclosed GitHub release lookup)	site-check
check-urls	every published URL and anchor still exists	site-check
dmg-resolve, dmg-download, dmg-package, dmg-verify, dmg-release	the five steps of publishing a DMG release, each reading its inputs from the environment (docs/distribution.md)	publish-dmg.yml
dmg-check DMG=...	sanity-check a disk image before publishing	dmg-package runs the same script (check-dmg.sh)
dmg-sync-docs	after a public release, start sync-docs.yml at the product tag desktop-<version>	publish-dmg.yml
docs-cli-reference	regenerate the CLI reference pages in the product checkout from its CLI schema and parser, before the sync (docs/deploy.md)	sync-docs.yml
docs-sync REF=...	copy the product docs from a blowhorn checkout into content/en/docs/ (docs/deploy.md)	sync-docs.yml
docs-sync-base	check out the docs-sync branch on the open sync PR's head, or on master when none is open (docs/deploy.md)	sync-docs.yml
docs-sync-start-checks	start site.yml on the docs-sync branch after a sync (docs/deploy.md)	sync-docs.yml
product-ci SUITE=python|desktop	run the private product repo's CI on a checkout of it, printing only step results and pass/fail counts (output stays in a private log; public logs never show product code)	product-ci.yml

Each check target builds for production first, so it also runs on its own. labeler.yml, label-commenter.yml and slack.yml only call third-party actions and run no repository logic, so they have no target.

The site follows the brand kit exactly: every colour, type style, spacing, radius and shadow in assets/css/site.css is a token from static/assets/brand/tokens.json. Brand SVGs are used as files and never recoloured. The one-to-many hero illustration and the platform marks are inline SVG drawn in currentColor.

Themes

A theme is presentation: tokens, CSS, and layout partials that read the same data and content. Reveille copy is approved. Signal and any future theme do not get their own copy of a page. Do not add content/en/home-signal.md or another theme-named content file; make check-theme fails those. The one approved exception is content/en/home-reveille.md, which keeps today's homepage at /home-reveille/ so we can still look at it.

Reveille is the site-wide default (light, dark follows the OS). Signal is a dark token layer on the public home page (theme: signal in content/en/_index.md). Homepage layout still comes from the theme's home field in data/themes.json (layouts/_partials/home/signal.html vs reveille.html); those partials consume data/integrations.json, data/actions.json, data/platforms/*.yaml and the same Markdown. ?theme=signal and ?theme=reveille swap the token layer on any page; they do not change homepage layout (/ stays Signal, /home-reveille/ stays today's look).

Nothing on the site loads from another host except Google Analytics 4: no CDN and no web fonts from elsewhere. The id is in [services.googleAnalytics] in hugo.toml. layouts/_partials/analytics.html loads gtag.js on every production page, enables analytics storage and keeps advertising storage denied. It renders only in production builds. The other request to another host while browsing is the download page's release lookup on GitHub's API (assets/js/download.js). The footer newsletter form posts to Layer5's Mailchimp list only when submitted. The privacy page discloses all three. make site-check fails a build that loads anything else from another host. The public URLs (/, /privacy.html, /terms.html, /assets/brand/...) and the home page's anchors (#platforms, #how, #trust, #download) are linked from outside this repository; the same check fails a build that loses one.

The site also publishes /llms.txt, /llms-full.txt and a Markdown copy of every page (/legal/privacy/index.md), as docs.layer5.io does.

CI

Workflow	When	What it does
site.yml	Pull requests, pushes to master, manual runs	Lints the workflows, runs the check-script unit tests, builds the site with the pinned Hugo, Go and Node.js, runs make site-check and uploads the Pages artifact. On master it deploys the artifact to GitHub Pages.
publish-dmg.yml	Manual, or repository_dispatch (publish-dmg) from product CI	Downloads a built DMG over HTTPS, checks it, verifies signing and notarization on a macOS runner (required for any public release), then creates the release with versioned assets, the Blowhorn-mac.dmg alias and checksums. Drafts by default; never overwrites.
sync-docs.yml	Manual, or repository_dispatch (sync-docs) from product CI	Checks out the product docs at the requested ref, opens or updates the docs-sync pull request (docs: sync from <ref>), and starts the site checks on it itself (gh workflow run site.yml); merging deploys once those checks pass.

 

Join the Layer5 community!

Our projects are community-built and welcome collaboration. 👍 Be sure to see the Layer5 Community Welcome Guide for a tour of resources available to you and jump into our Slack!

Find your MeshMate

MeshMates are experienced Layer5 community members, who will help you learn your way around, discover live projects and expand your community network. Become a Meshtee today!

Find out more on the Layer5 community.

 

✔️ Join any or all of the weekly meetings on community calendar.
✔️ Watch community meeting recordings.
✔️ Access the Community Drive by completing a community Member Form.
✔️ Discuss in the Community Forum.
✔️Explore more in the Community Handbook.

Not sure where to start? Grab an open issue with the help-wanted label.