Add Ship to
your project.

Run the installer from the Git root.

The shell downloads reviewed TypeScript to a temporary file, Bun runs it with terminal prompts, then the file is removed.

curl -fsSL https://shibumistack.dev/install/ship.sh | sh

The installer checks the Git root, adds Ship source and package commands, and starts setup. It never replaces an edited scripts/ship.ts.

Setup asks two questions: the SSH target you already use and the app domain. Then it prints a plan and runs all of it on one Run setup? confirm. The domain question appears only when the package name and Compose SITE_URL cannot answer it.

●  Plan
│  Create private repo bitbonsai/quiet-bamboo, push main
│  Connect to alpha, save target for this project
│  Install or upgrade shibumi-server (sudo password once)
│  Register quiet-bamboo.dev
│  Commit and push deployment files
│  Deploys run on: bun ship

Nothing lands on disk before you accept the plan. The GitHub sign-in and the Caddy cutover still ask for themselves, because one opens a browser and the other moves live traffic. bun ship:setup --interactive puts a gate back on every step.

A project without a GitHub origin is fine. Setup offers to create the repository and push it, private by default, --public for the other kind.

Setup ends with a Ship now? confirm: Enter runs the first deploy in the same session.

When no tracked Compose file exists, setup can generate a Bun Dockerfile, loopback-only compose.yaml, and .dockerignore. Review and commit them before resuming. Existing files are never replaced.

Setup installs no webhook. bun ship already uploads the exact image and asks the server to deploy that commit. Pushes deploy only if you opt in with bun ship:webhook, and bun ship:webhook --off reverses it. If DNS is not ready, setup keeps the generated files and prints the command to resume.

Cloudflare: Push-to-deploy requires Full (strict) SSL/TLS mode for proxied domains.

Review the files added.

The original development command moves to dev:app. bun dev runs it on the app port stored in shibumi-server.json.

{
  "scripts": {
    "dev": "bun scripts/ship.ts --dev",
    "dev:app": "<original dev command>",
    "ship": "bun scripts/ship.ts",
    "ship:setup": "bun scripts/ship.ts --setup",
    "ship:update": "bun scripts/ship.ts --update",
    "ship:logs": "bun scripts/ship.ts --logs",
    "ship:status": "bun scripts/ship.ts --status",
    "ship:webhook": "bun scripts/ship.ts --webhook"
  },
  "devDependencies": {
    "@clack/prompts": "^1.7.0"
  }
}

Read the full source: ship.ts on GitHub or the published /ship/latest.ts.

Committed

scripts/ship.ts, shibumi-server.json, and package changes

Local only

SSH targets in ~/.config/shibumi/config.json

Server only

Checkout path, machine config, and webhook secret

Build committed HEAD and upload it.

bun ship

Before tests and builds, Ship can run a newer reviewed version of its own source. It writes that version to tracked scripts/ship.ts only after a successful deployment and leaves the edit unstaged.

Ship requires a clean configured branch. It runs project checks, builds exact HEAD for the server's Linux platform, labels the image with repository, app, revision, Git tree, and platform, then uploads it through SSH. Git pushes only after upload. The server verifies each identity value before deployment. Ship never stages or commits files.

Docker cache stays enabled. bun ship --rebuild passes --no-cache. If a local preflight stops the deploy, use the Ship troubleshooting guide.

Existing domains keep their current Caddy upstream until the first deployment passes health and you approve cutover. Use bun ship:status for state, bun ship:logs for the latest log, or bun ship --rollback to restore the retained image.

Agents can use bun ship -y for routine confirmations. Bun forwards -y directly, so no -- separator is needed. Git, test, image, and deployment checks still run.

The shibumi-server page documents what the server checks before it swaps a container.