Blowhorn site and downloads
This repository is two things for Layer5 Blowhorn:
- 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://blowhorn-ai.github.io/blowhorn-site/ only redirects there; the site is reachable once the domain's DNS points at Pages, as docs/deploy.md describes.
- 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 (), the onboarding pages (), the redirect pages (), the 404 page, the header, footer and icon sprite partials, the and Markdown outputs, and the Docsy-based docs shell () |
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, product-ci.yml, internal-site.yml, internal-site-auto.yml and publish-blowhorn-axi.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/machines.json, data/home_ai.json, data/tells.json, data/roles.json, data/use_cases.json, data/solutions.json, data/themes.json, data/integrations.json, data/hero_demo.json, data/actions.json, data/action_examples.json and data/docs_events.json validate against schemas/; role, use-case and solution schemas $ref shared line/text/card types in schemas/defs/cast-page.schema.json, and the docs events schema its payload types in schemas/defs/docs-event.schema.json (ajv -r, docs/docs-attribution.md) (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) |
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 Blowhorn's own signup service only when submitted. The privacy page discloses all three. The MCP connection guides send three consent-gated GA4 events through that same tag (docs/docs-attribution.md). 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>), starts the site checks on it itself (gh workflow run site.yml), merges it once those checks pass, and starts the master run that deploys. |
internal-site.yml | Manual (make site-internal-deploy), repository_dispatch (deploy-internal-site) from the product repo, or called by internal-site-auto.yml | Builds the internal site from a read-only checkout of the product repo and deploys it to internal.blowhorn.ai behind Cloudflare Access (docs/deploy.md). |
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 out more on the Layer5 community.
