Web site on vanityURLs Brand

Local development

Mon, 01 Jan 0001 00:00:00 +0000

Use this page when you are changing layouts, content, styles, search, or the small Cloudflare Worker that serves the documentation site.

Prerequisites

Tool	Version	Why
Hugo Extended	`0.158.0+`	The site uses Hugo asset pipeline features that require a modern extended build
Node.js	`20+`	npm scripts, Tailwind, PostCSS, Pagefind, Wrangler, and tests
Git	Any modern version	`enableGitInfo` uses commit metadata for last-modified dates
Go	Optional	Only needed if you build Hugo yourself

Use Hugo Extended

Content authoring

Mon, 01 Jan 0001 00:00:00 +0000

Use this page when you add or update website content in content/, i18n/, data/, or Hugo layouts/.

Repository areas

Path	Purpose
`content/`	Pages, blog posts, showcase entries, and documentation
`layouts/`	Hugo templates, partials, and shortcodes
`assets/`	Processed CSS and JavaScript that Hugo fingerprints
`static/`	Files copied as-is with stable public URLs
`data/`	Structured page data such as home, FAQ, glossary, trust, and audits
`i18n/`	UI strings used by templates and shortcodes

Content files

Use language-specific filenames:

Documentation contribution

Mon, 01 Jan 0001 00:00:00 +0000

The main site has a short Contribution Guide for code, documentation, bug reports, and community help. This page adds the brand-site expectations for documentation contributors.

Where to contribute

Work	Repository
Redirector code	`github.com/vanityURLs/vanityURLs`
Main website docs	`github.com/vanityURLs/website`, under `content/`
Brand standards docs	`github.com/vanityURLs/website`, under `brand-content/`
Website templates	`github.com/vanityURLs/website`, under `layouts/`
CSS and JavaScript	`github.com/vanityURLs/website`, under `assets/`
Stable public downloads	`github.com/vanityURLs/website`, under `static/`

Brand documentation rules

Keep pages practical and source-of-truth oriented.
Base standards on existing implementation before inventing a new rule.
Add English and French pages together when the section is bilingual.
Use brand-content/ for brand standards and content/ for the main product site.
Link back to the main site when a visitor needs product documentation, legal pages, trust pages, or community entry points.
Use conventional commits so release-please can classify changes.

Before opening a pull request

Run:

Hosting and deployment

Mon, 01 Jan 0001 00:00:00 +0000

The documentation site runs on Workers Static Assets with Cloudflare Workers. It is not a Cloudflare Pages project. One Worker serves the Hugo-generated static site and handles server-side analytics for HTML page views.

Architecture

flowchart LR
A[GitHub
main branch]
B[Cloudflare GitHub
integration]
C[build.sh]
D[Hugo build
and Pagefind index]
E[wrangler deploy]
F[Worker
vanityurls-website]
G[Static Assets binding
./public]
H[Custom domain
vanityurls.link]

A --> B
B --> C
C --> D
D --> E
E --> F
F --> G
F --> H

The Worker is configured so HTML requests pass through src/worker.mjs; and everything else is cheap static asset traffic such as CSS, fonts, JavaScript bundles, images, Pagefind files, and sitemaps that bypass Worker code.

Website analytics

Mon, 01 Jan 0001 00:00:00 +0000

The website uses Umami for visitor analytics. Events are sent server-side from the Cloudflare Worker instead of through a browser JavaScript snippet.

Privacy model

The website analytics setup is intentionally small:

no analytics cookies
no client-side analytics script
no localStorage or sessionStorage for tracking
no browser fingerprinting
no full visitor IP address sent to Umami

The Worker truncates visitor IP addresses before forwarding analytics data: IPv4 to /24 and IPv6 to /48. That preserves coarse geography while removing household-level precision.

Releases

Mon, 01 Jan 0001 00:00:00 +0000

The website repository uses release-please through GitHub Actions. Releases are driven by commit history and release-please metadata, not by hand-editing package versions.

flowchart LR
A[Conventional
commits]
B[GitHub
Actions]
C[release-please]
D[Release PR]
E[CHANGELOG.md]
F[package
versions]
G[release
manifest]
H[GitHub
release]

A --> B
B --> C
C --> D
D --> E
D --> F
D --> G
D --> H

Before merging a release-facing website change:

Run npm run build.
Run npm run lint or the relevant narrower check.
Confirm .release-please-manifest.json still matches the intended current release.
Avoid manual edits to generated release notes unless you are correcting release metadata.

Changelog handling