Deploy

What goes up

You upload built output: a directory, or a .tar.gz or .tgz archive of one. Other archive formats are rejected. You build on your own machine or CI runner, and source code never reaches the service.

A directory deploy leaves out every name that starts with a dot, .well-known/ included. See kamakiri deploy.

Each deploy is an immutable snapshot, and a rollback puts an earlier one back online without uploading anything.

kamakiri deploy returns once every cache a visitor could hit serves the new deploy. kamakiri deploy covers the wait, --no-wait and the exit codes.

Default limits

A deploy over the size or file limit is rejected, and nothing is stored. A deploy is never rejected for the retained count: once a site holds more than five, the oldest are deleted, never the one being served. kamakiri status shows the sites and retained deploys you use against their limits, and the deploy size limit.

Roll back

kamakiri deploys lists the retained deploys, newest first, and marks the one being served live. Only these can be rolled back to.

$ kamakiri deploys
ID                   Status  Created
20260919-165352-453  live    2026-09-19 16:53:52 UTC
20260919-165350-000          2026-09-19 16:53:50 UTC
20260919-165349-736          2026-09-19 16:53:49 UTC
$ kamakiri deploys
デプロイID           状態    作成日時
20260919-165352-453  公開中  2026-09-19 16:53:52 UTC
20260919-165350-000          2026-09-19 16:53:50 UTC
20260919-165349-736          2026-09-19 16:53:49 UTC

kamakiri rollback publishes one of them again and waits the way a deploy does.

$ kamakiri rollback 20260919-165349-736
Rolled back to 20260919-165349-736
✓ live: https://my-site.kamakiri-pages.jp
$ kamakiri rollback 20260919-165349-736
20260919-165349-736 にロールバックしました
✓ 公開中: https://my-site.kamakiri-pages.jp

The files at the root of a deploy

_redirects and _headers are not served as files. All three belong to the deploy they ship in, so a rollback restores that deploy’s redirects, headers and 404 page along with its files.

Deploy from CI

A CI runner authenticates with the KAMAKIRI_API_KEY environment variable. Its value is the api_key field in ~/.config/kamakiri/credentials.json on the machine where you ran kamakiri login. The client never prints the key, so copy it from that file into a repository secret. Logging in again later mints a new key and leaves this one valid.

kamakiri deploy waits in CI exactly as it does on your machine, with no timeout. Pass --no-wait if the job should end once the upload is accepted.

This GitHub Actions job deploys on every push to main. The checkout brings the committed .kamakiri/config.json, which names the site.

name: Deploy
on:
  push:
    branches: [main]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - name: Install the client
        run: curl -fsSL https://get.kamakiri-labs.jp/install.sh | sh
      - name: Build
        run: npm ci && npm run build
      - name: Deploy
        env:
          KAMAKIRI_API_KEY: ${{ secrets.KAMAKIRI_API_KEY }}
        run: $HOME/.local/bin/kamakiri deploy ./dist

Give the key to the deploy step alone, so the build never runs with it in its environment.