Skip to content

Acquire briosa.dev and make it the canonical documentation URL #9

Description

@davidalucas

Summary

Acquire briosa.dev for the Briosa project and configure it as the canonical public URL for the Docusaurus documentation site currently published at https://spatialanalyzer.github.io/briosa-docs/.

This issue covers ownership and governance, DNS, GitHub Pages custom-domain setup, Docusaurus URL configuration, canonical and redirect behavior, HTTPS validation, and operational handoff. Domain purchase and registrar selection require maintainer authorization and should not occur until ownership and renewal responsibility are explicit.

Decisions required before purchase

  • Identify the legal person or organization that will be the registrant and administrative contact.
  • Confirm who pays for registration and recurring renewals.
  • Choose a registrar with strong account security, DNSSEC support, transfer lock, recovery controls, and exportable DNS.
  • Confirm whether the organization will use:
    • apex https://briosa.dev/ as canonical; and
    • www.briosa.dev as a redirect or alternate hostname.
  • Confirm whether future non-documentation services are expected under subdomains.

Proposed implementation

  • Acquire briosa.dev only after ownership and renewal decisions are recorded.
  • Verify the custom domain with the spatialanalyzer GitHub organization before attaching it to Pages to reduce takeover risk.
  • Configure DNS according to current GitHub Pages guidance.
  • Add the repository Pages custom domain and commit the resulting CNAME file if GitHub requires it for this workflow.
  • Change the Docusaurus url to https://briosa.dev and baseUrl to /.
  • Review navbar, footer, edit links, sitemap and robots output, Open Graph metadata, canonical links, and absolute URLs.
  • Keep GitHub Pages HTTPS enforcement enabled and wait for certificate issuance before announcing cutover.
  • Ensure the old https://spatialanalyzer.github.io/briosa-docs/ address reaches or canonicalizes to the custom domain as GitHub Pages supports; document any redirect limitation rather than assuming it.
  • Define monitoring, renewal reminders, registrar recovery, and rollback.

Acceptance criteria

  • Registrant, billing owner, administrative contacts, renewal owner, and recovery procedure are documented in an appropriate private governance location; no private credentials or personal contact details are committed publicly.
  • briosa.dev is registered with MFA or passkey protection, registrar lock, auto-renewal, and a tested recovery path.
  • The domain is verified for the GitHub organization before it is attached to Pages.
  • Apex and optional www DNS records are configured and documented without exposing secrets.
  • GitHub Pages reports the custom domain as healthy and HTTPS enforcement is active.
  • https://briosa.dev/ is the canonical site URL and all generated routes and assets work from /.
  • The old GitHub Pages project URL has documented redirect or canonical behavior and does not create an unmanaged duplicate-content surface.
  • Canonical metadata, sitemap, robots, Open Graph, and internal links reference briosa.dev.
  • CI and build validation pass, including broken-link checks.
  • A rollback procedure restores the prior GitHub Pages URL and configuration if DNS or certificate issuance fails.
  • Domain renewal and expiry monitoring is in place with at least two independent reminders or contacts.

Constraints

  • Do not purchase or transfer the domain until ownership, payment, renewal, and recovery responsibilities are explicitly approved.
  • Do not place registrar credentials, authorization codes, billing data, private contact details, or DNS provider secrets in the repository.
  • The site remains public and static; the domain change does not authorize remote Briosa server exposure or change loopback and security guidance.
  • Preserve the independent-project disclaimer and avoid implying Hexagon affiliation, endorsement, or support.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    documentationImprovements or additions to documentationenhancementNew feature or request

    Type

    No type

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions