A GitHub Pages alternative for when the site is not a repo

Moving a site from GitHub Pages

What your configuration maps to, what has no equivalent at all, and the order to do it in. The middle one is the part that decides whether this is an afternoon.

What maps to what

What has no equivalent

Handle these before you move DNS, not after. Pages serves files: it has an SPA fallback, custom error pages and an exclude list, and it has no redirect table and no custom response headers.

• Jekyll running on the host. This is the real work of the move: the build becomes yours to run. For a default Jekyll site that is a handful of workflow lines; for a heavily plugin-dependent one, check it builds locally first.
• The repo-is-the-site model. Anything that assumed committing publishes — a CMS writing to the branch, a bot opening content PRs — needs to route through the build instead.
• Redirect rules and custom headers. Neither exists here; GitHub Pages has little of either, so this is usually a non-issue on this particular move.

The order to do it in

1. STEP 01

   Get the build running outside GitHub Pages

   If GitHub was building Jekyll for you, that build becomes yours. Run it locally once and confirm the output — a site leaning on plugins the GitHub build whitelisted is better discovered now than in CI.
   locally

   $ bundle exec jekyll build
   $ ls _site

2. STEP 02

   Drop the path prefix

   A project site served from /reponame carries a baseurl (Jekyll), base (Vite, Astro) or basePath (Next.js). Here the site is at the root of its own host, so that setting comes out — otherwise every asset URL keeps a directory that no longer exists.
   _config.yml

   -baseurl: "/reponame"
   +baseurl: ""

3. STEP 03

   Create the site and a CI token

   A site has to exist before anything can deploy to it — the action will not create one, so a typo fails instead of quietly publishing to a new address. Do both from the dashboard if you prefer.
   once

   $ one9x pages create mysite
   ✓ created mysite → https://mysite.one9x.app/
   $ one9x tokens create "github actions"
   one9x_tok_7Kd…  (shown once)

4. STEP 04

   Deploy the output folder

   Same folder GitHub was publishing, handed over directly. The release stages first, with its own URL, so you can compare it against the live Pages site side by side.
   first deploy

   $ one9x pages release ./_site --site mysite --error 404:/404.html
   ✓ v1 staged → https://v1--mysite.one9x.app/

5. STEP 05

   Swap the deploy step in CI

   This is the whole change for most GitHub Pages sites. The repo does not move; only where it deploys to. Three official Pages steps become one, and the pages: write / id-token: write permissions and the github-pages environment block come out with them.
   before

   - uses: actions/configure-pages@v5
   - uses: actions/upload-pages-artifact@v3
     with:
       path: ./_site
   - uses: actions/deploy-pages@v4

   after

   - uses: one9x/pages-deploy@v1
     with:
       site: mysite
       dir: _site
       token: ${{ secrets.ONE9X_TOKEN }}
       deploy: ${{ github.ref == 'refs/heads/main' }}
       comment: true

6. STEP 06

   Cut the domain over

   Lower the TTL a day ahead, link the domain here, publish the records we print, wait for the certificate. Do not touch the repo yet.

7. STEP 07

   Only now, turn Pages off

   Delete the CNAME file and disable Pages in repository settings — in that order, and only after the domain is serving from here. Reversed, the domain is briefly claimed by two hosts and one of them wins at random. .nojekyll can go too; nothing here processes your files.

Your live site on GitHub Pages keeps serving throughout — nothing here touches it until you move DNS, and the free plan is enough to do the whole rehearsal first.