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

RoutePurpose
/appsHub listing all three desktop apps
/apps/{slug}Product page — hero, features, tech stack
/apps/{slug}/downloadPlatform 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:

  1. scripts/mirror-app-releases.sh pulls assets from GitHub via gh release download
  2. Files land in .downloads-staging/ with a SHA-256 manifest.json
  3. scripts/deploy-hostinger.sh rsyncs dist/ 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 — unauthenticated urllib fetches 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.gz but Gnomad ships 0.2.0-1-darwin.dmg, a single apps.ts file prevents broken links.
  • Gitignore the heavy stuff — staging and mirrored binaries stay local until deploy.

Deploy docs: deploy/HOSTINGER.md in the site repo.