Kamakiri PagesJoin the beta

kamakiri deploy

Usage

kamakiri deploy <path> [--no-wait]

<path> is a directory of built output, or a .tar.gz or .tgz archive of one. Other archive formats are refused. Deploy covers what a deploy is, the limits it lives under, rollback and deploying from CI.

$ kamakiri deploy ./dist
Uploading 2 files (0.3 KB)... done (0.0s).
Deploying...

Deploy: 20260919-165349-736
✓ live: https://my-site.kamakiri-pages.jp

$ kamakiri deploy ./dist
アップロード中: 2件のファイル (0.3 KB)... 完了しました（0.0秒）。
デプロイ中...

デプロイ: 20260919-165349-736
✓ 公開中: https://my-site.kamakiri-pages.jp

The command returns once the site is live. The ✓ live line names the URL a visitor uses: your canonical custom domain once it serves over HTTPS, and the kamakiri subdomain otherwise. When neither is serving, the line carries no URL. A long wait adds its approximate length, as in ✓ live: https://example.com (~42s).

Above about 50 MB, the upload line shows a counter that updates as the bytes go. The time on that line runs until the service accepts the upload, and does not include the wait that follows.

What a directory uploads

Files and directories whose names start with a dot are left out, so .git, .env and .well-known/ are never uploaded. A symbolic link to a file is packed as its target, unless the target’s name starts with a dot, in which case it is left out. A link to a directory fails the deploy with a read error, and a link that points outside the directory you deploy stops the deploy.

A line in _redirects or _headers that the service would refuse stops the deploy before anything is uploaded, and the error names the line. An archive is not checked this way: the service checks it after the upload.

Returning before the site is live

--no-wait returns as soon as the upload is accepted. The → line is the site’s address, not a sign that it serves the new deploy yet.

$ kamakiri deploy ./dist --no-wait
Uploading 5 files (0.4 KB)... done (0.0s).
Deploying... queued (--no-wait).

Deploy: 20260919-165352-453
→ https://my-site.kamakiri-pages.jp
Publishing continues in the background; check kamakiri status.

$ kamakiri deploy ./dist --no-wait
アップロード中: 5件のファイル (0.4 KB)... 完了しました（0.0秒）。
デプロイ中... 処理を受け付けました (--no-wait)。

デプロイ: 20260919-165352-453
→ https://my-site.kamakiri-pages.jp
公開処理はバックグラウンドで続きます。kamakiri status で確認してください。

When the wait stops on something you must fix

If a CDN cache cannot be flushed until you act, the wait stops. The ✗ line says what did not happen, and the line under it says how to clear it.

$ kamakiri deploy ./dist
Deploy: 20260301-143022-384
✗ Deployed, but the WebAccel cache was not flushed: the stored credentials were rejected.
  Run kamakiri cdn credentials to update them; once they are accepted the flush retries and completes on its own.

$ kamakiri deploy ./dist
デプロイ: 20260301-143022-384
✗ デプロイは完了しましたが、WebAccel のキャッシュをクリアできませんでした: 保存されている認証情報が拒否されました。
  kamakiri cdn credentials を実行して更新してください。認証情報が受け付けられると、キャッシュのクリアは自動的に再試行されて完了します。

The deploy is stored and the site points at it; only the cache in front of it is stale. Once you clear the condition, the flush retries on its own, and kamakiri status shows the site live. kamakiri cdn covers the credentials in this example.

Before a site is linked

Until kamakiri init links the directory to a site, the command uploads nothing.

$ kamakiri deploy ./dist
no site linked. Run "kamakiri init" first

$ kamakiri deploy ./dist
サイトがリンクされていません。先に "kamakiri init" を実行してください

The credential is checked before the link, so on a machine that has not run kamakiri login, the command reports that instead.

Exit status