Deploying

archival builds a plain static site into your build_dir (dist by default), which means you can host it just about anywhere. You have a few options, from fully automated archival hosting to deploying the static output yourself.

If you created your site through editor.archival.dev, publishing is already handled for you. archival hosts your site, and changes you make in the editor — or push to your connected git repository — are built and deployed automatically. You can point a purchased or existing domain at your site from its settings. For most people, this is all you need.

If you manage your site in your own GitHub repository and want archival to host it, use the archival GitHub Action. It installs archival, runs your prebuild commands, builds the site, and syncs the result to archival’s hosting:

# .github/workflows/archival.yml
name: archival
on:
  push:
    branches: [main]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Archival Build
        uses: archival-dev/archival@main

The action accepts a few optional inputs:

• archival-version — the version of archival to install from cargo (e.g. 0.14.0).
• archival-bin — a path to an existing archival binary to use instead of installing one.
• api-host — the archival API host that build events are sent to (defaults to https://api.archival.dev).

A site archival hosts can put some or all of its pages behind a username and password. Add a Basic-Auth line under the path it protects in the _headers file at the root of your build — public/_headers for most sites:

/*
  Basic-Auth: alex:correct-horse jamie:battery-staple

Every user:password pair on the line can sign in, separated by spaces. Browsers ask for the username and password, and tools that fetch your pages, like curl or a feed reader, can send them in the URL: https://alex:correct-horse@example.com/feed.xml.

Paths use the same patterns as the rest of _headers. * matches anything, so /members/* protects everything under /members/, and :name matches one segment of a path, as in /posts/:slug/draft. When more than one rule matches a page, a pair from any of them signs in. A rule with no pairs on its line locks its pages for everyone.

A few things to know:

• Basic-Auth lines are never sent as headers, and archival keeps only a hash of each password. The password is still written out in your site's source, so anyone who can read the source can sign in.
• A change takes up to two minutes after a deploy to reach every visitor.
• The editor's preview and archival run don't ask for a password.
• Only pages fetched from your site are protected. If your site federates with ActivityPub, its posts are still delivered to its followers.

Because archival build produces an ordinary static site, you can deploy the dist folder to any static host — GitHub Pages, Cloudflare Pages, Netlify, S3, or your own server. The general recipe is:

1. Install archival (cargo install archival, or cargo binstall archival).
2. If your site uses a javascript or css toolchain, run archival prebuild first so those assets exist. TypeScript in scripts/ is built by archival build itself and needs no prebuild.
3. Run archival build.
4. Publish the contents of dist.

As an example, here’s how you would deploy an archival site to Cloudflare Pages via github actions:

publish-pages:
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v3
    - name: Install archival
      uses: taiki-e/install-action@v2
      with:
        tool: cargo-binstall
    - run: cargo binstall --no-confirm archival
    - run: archival build
    - name: Deploy
      uses: cloudflare/wrangler-action@v3
      with:
        apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}
        command: pages deploy dist --project-name=your-project

If you pin a minimum archival version in your archival.toml, you can guard your CI against accidentally building with an incompatible version by running archival compat <version> — it exits non-zero when the versions don’t match. See the compat command for details.