Fjord

Custom domains for Forgejo Pages

Custom domains should be the last step after the build, deploy path, and rollback story are stable.

Pages

What this solves

You want a Pages deployment served from your own hostname.

Best fit

  • Documentation domains
  • Project websites
  • Customer-facing static sites

How to think about it

Domain setup is operational, not just cosmetic. First prove the generated site works on the default Pages hostname, then move DNS with a rollback plan and clear ownership for the repository, workflow, and domain.

DNS rollout checklist

1. Deploy to the default Pages hostname
2. Verify HTTPS, redirects, assets, and canonical URLs
3. Lower DNS TTL before cutover
4. Point the custom hostname
5. Check certificates and rollback path

Practical path

  1. 01 Deploy successfully on the default Pages hostname first.
  2. 02 Point DNS only after the site is stable.
  3. 03 Keep repository, workflow, and DNS ownership documented for incident response.

When to choose another path

Keep DNS ownership documented with the repository owner.

Verify canonical URLs and redirects after cutover.

Do not debug build failures and DNS failures at the same time.

Next resources

Pages docs

How Fjord Pages deploys static sites.

Actions docs

Workflow basics for deploy jobs.

CLI

Trigger and inspect deploy workflows.

Operations

Run the forge behind the site calmly.

Related reading

Deploy Astro to Forgejo Pages

Deploy an Astro site with Forgejo Actions and Fjord Pages: install dependencies, build to dist, and publish the static output straight from a workflow.

Deploy Hugo to Forgejo Pages

Deploy a Hugo site from Forgejo Actions to Fjord Pages: pin the Hugo version, build to public, and publish the generated output on every push.

Deploy MkDocs to Forgejo Pages

Publish MkDocs documentation with Forgejo Actions and Fjord Pages: build the site from the repository and ship the exact generated output.