Rendered from docs/ops/dns.md, which is the source of truth and the markdown twin of this page. Rendered at site v0.1.2.

DNS for secrets.sgit.ai

secrets.sgit.ai · operations · written at v0.1.0 (2026-10-05) · for the owner of the sgit.ai zone · CC BY 4.0

The site is served by GitHub Pages from the repository SGit-AI/SGit-AI__Website__Secrets. The repository already carries CNAME with the one line secrets.sgit.ai. Two things are needed from the zone owner and the repository admin, in this order.

1. The DNS record

In the sgit.ai zone add one record:

Name	Type	Value	TTL
`secrets`	`CNAME`	`sgit-ai.github.io`	3600 or the zone default

Do not use an A record to the Pages IP addresses for this host; the CNAME to the organisation's Pages host is what GitHub recommends for a subdomain and what lets GitHub rotate addresses.

2. GitHub Pages on the repository

In the repository, Settings, Pages:

Source: GitHub Actions (not "deploy from a branch"). The workflow deploy-pages.yml publishes the artifact.
Custom domain: secrets.sgit.ai. Save. GitHub checks the DNS record and then provisions the certificate, which can take up to an hour after the record propagates.
Tick Enforce HTTPS once the certificate is issued.

3. What then happens by itself

The next run of deploy-pages.yml on dev (or a manual dispatch of it) deploys, and its verify-live job turns green when https://secrets.sgit.ai/admin/build/version.txt serves the released version. Until the record and the Pages settings exist, verify-live is red by design.

Guards the security page will list, dated

These are the zone owner's decisions and are listed on /security/ once it exists, with the date they were checked:

Registrar lock on sgit.ai.
DNSSEC on the zone.
A CAA record limiting certificate issuance (GitHub Pages uses Let's Encrypt: 0 issue "letsencrypt.org").
The sgit.ai domain verified in the GitHub organisation (Settings, Verified and approved domains), which stops another account claiming a dangling *.sgit.ai subdomain on Pages.