rebase.page

01 — Publish

Your site on rebase.page

1. Choose the repository

   Its name decides the address. <user> may be a user or an organisation, and the repository must be public.

   • rebase.now/<user>/pageshttps://<user>.rebase.page/
   • rebase.now/<user>/<project>https://<user>.rebase.page/<project>/

2. Commit the built site to pages

   Commit the output, not the sources: plain HTML or the build of any static generator, with index.html at the top.

   git push origin pages

3. Add a webhook

   In the repository, open Settings → Webhooks and add a Forgejo webhook:

   Target URL

   the site address above

   HTTP method

   POST

   POST content type

   application/json

   Trigger on

   Push events

   Branch filter

   pages

4. Push, and it is live

   Every push to pages replaces the site atomically. Visitors keep seeing the previous version until the new one is complete. Recent deliveries in the webhook settings show the result of each update.

02 — Custom domains

Bring your own domain

Publish any repository's pages branch as the whole of a domain. Two DNS records name the repository and route the traffic:

_git-pages-repository.example.org.  TXT    "https://rebase.now/<owner>/<repo>.git"
example.org.                        CNAME  rebase.page.

• Use the clone URL exactly as rebase.now shows it, including the .git suffix.
• Most providers allow a CNAME at the apex (CNAME flattening); if yours does not, use the A records of rebase.page instead.
• Point the first webhook at http://example.org/: no certificate can be issued before the site exists. Once a delivery succeeds, switch it to https://. The first HTTPS request may be delayed by a few seconds.
• Each name, including subdomains such as www.example.org, needs its own records and webhook.
• Certificates come from ZeroSSL or Let's Encrypt. Most domains need nothing here; if you do set CAA records, allow both issuers.

03 — Good to know

Serving details