Launching the Gnomad Apps Hub on davidcole.cloud
Product pages, platform download cards, and a first-party mirror pipeline for Slate, Webcanvas, and the Gnomad desktop assistant.
- astro
- tauri
- hostinger
- downloads
- apps
The gap
GitHub Releases are fine for developers who already know the repos. They are not fine for a local business owner who clicked through from a portfolio link and landed on a release asset list with .sig files and latest.json.
I wanted davidcole.cloud to behave like a product site: marketing copy, feature grids, and download buttons that resolve to URLs I control — with GitHub as a secondary fallback.
What shipped
| Route | Purpose |
|---|---|
/apps | Hub listing all three desktop apps |
/apps/{slug} | Product page — hero, features, tech stack |
/apps/{slug}/download | Platform cards (Mac / Windows / Linux) with direct links |
The data layer lives in src/data/apps.ts: version strings, release tags, platform availability, and filenames under /downloads/{slug}/.
Download infrastructure
Installers are not checked into git. The flow:
scripts/mirror-app-releases.shpulls assets from GitHub viagh release download- Files land in
.downloads-staging/with a SHA-256manifest.json scripts/deploy-hostinger.shrsyncsdist/to the site root and staging to/downloads/
public/downloads/.htaccess sets attachment-friendly headers for binary downloads on Apache/Hostinger.
Lessons
- Authenticate downloads with
gh— unauthenticatedurllibfetches hit 404 on some GitHub assets; the CLI handles redirects and auth correctly. - Keep marketing and filenames in one config — when Slate ships
.app.tar.gzbut Gnomad ships0.2.0-1-darwin.dmg, a singleapps.tsfile prevents broken links. - Gitignore the heavy stuff — staging and mirrored binaries stay local until deploy.
Links
Deploy docs: deploy/HOSTINGER.md in the site repo.