Verify every push.
The webhook must match the secret, repository, branch, and commit. Bad or repeated requests do not deploy.
Self-hosted deploys
Push,
done.
A small Bun service that deploys your app to your VPS or homelab server.
Open source · v0.6.3
›
渋み shis (shibumi-server)
Received GitHub push
Verified webhook, repo, branch, and commit
Checked memory and disk
Validated Compose configuration
Built with rootless Podman
Replaced container and passed health check
Kept two rollback images and cleaned older ones
What do these checks mean?
Every deploy runs the same checks. You do not need to write tests for them.
- Verify the webhook, repository, branch, and commit.
- Check free memory and disk space.
- Validate the Compose configuration.
- Build the image and run any optional app tests in a temporary container.
- Replace the old container, check the new one's local health endpoint, keep the previous two successful images for rollbacks, and remove older images.
App tests are optional. Add a command such as bun test only when the project has its own test suite.
Small on purpose
No dashboard.
No cloud deploy service.
GitHub sends a webhook when you push. Your current app keeps running while shibumi-server verifies the push, checks the host, validates the setup, and builds the new image. If those steps pass, it replaces the old container, checks the new one's health behind Caddy, keeps the previous two images for quick rollbacks, and removes older ones.
Built for small servers.
Before building, shibumi-server checks free memory and disk space. A build that runs too long is stopped.
Bad builds don't go live.
Only one deploy runs at a time. Invalid configuration or a failed build stops before startup.
Dogfooding with MCPVault
Testing for real.
I also maintain MCPVault, the open-source MCP bridge for Obsidian. Its Astro website had become more machinery than the site needed. Astro 7 moved its Cloudflare deploy from Pages to Workers, adding another adapter and more platform-specific complexity, so I'm rebuilding it with Shibumi on a tiny VPS.
The first build exhausted the server's memory. That failure led directly to pre-build memory and disk checks, plus a timeout for builds that run too long.
Visit MCPVault →Install
Install once
on your server.
Start with a Linux VPS or homelab server. Setup uses Bun, Git, rootless Podman, Caddy, and systemd, checking the host before it changes server configuration.
›
渋み shis (shibumi-server)
Server requirementsGit ✓Podman ✓Caddy ✓systemd ✓
Install shibumi-server on this server?Yes
Installed shibumi-server 0.6.3
Next: shis add example.com
The installer stages the release with lockfile-pinned production dependencies before activation. The installed service keeps using that exact release until you upgrade it. User-run commands check for newer releases and suggest shibumi-server update. Update installs the exact stable release reported by npm while preserving config and secrets. Registry problems never block local work.
shibumi-server uninstall removes the service and installed code while preserving config and secrets. Add --purge to remove those too after confirmation. App checkouts, containers, Caddy, and GitHub settings stay untouched.
Apps
Adding apps
is a breeze.
Use the installed command with a domain. It checks DNS and existing Caddy routes, asks for the repository and deployment directory, assigns an available local port, then previews the complete setup before changing anything.
›
渋み shis (shibumi-server)
DNS detected (cloudflare)
Where's the repository?https://github.com/bitbonsai/example
Where should deployments live?/home/user/shibumi/sub-example-com
Health path /healthz (default)
Domain configuration● Recommended defaults (zstd + gzip, indexing allowed, safe headers, rotated logs)
○ Customize…
○ Customize…
App ready at https://sub.example.com
Want to check it first? Run shibumi-server add sub.example.com --dry-run. It uses the same detection, prompts, port selection, and validation, then prints the app ID, checkout, webhook URL, secret variable, and Caddy upstream without writing config or secrets, invoking sudo, or changing Caddy or systemd.
A real add prepares the checkout and asks sudo only when its constrained helper saves, validates, and reloads Caddy. GitHub setup stays on your project machine through bun run ship. Repeat the command for every app or domain.
Automation can pass the repository as github:owner/repo, plus the checkout and port, as flags to skip the prompts. Domain-derived app IDs escape literal hyphens so dashed labels cannot collide with dots.
Ship
Push with
one command.
Self-hosted projects own a small ship script:
bun run shipFirst run detects missing setup, explains what stays local, then opens the server flow through confirmed SSH. The server checks DNS, prepares Caddy, and returns commit-safe shibumi-server.json. GitHub CLI creates the webhook without printing or storing its secret.
Later runs check Git state, run project tests and type checks, push, then follow deployment status over SSH. Existing domains keep their current upstream until the first Shibumi deployment is healthy and you confirm Caddy cutover.
Run bun run ship:setup whenever you want to review or change deployment setup. Existing project? Add the owned ship workflow.
Run it yourself
Install on your server.
Requires Linux with Bun, Git, rootless Podman, Caddy, and systemd. On macOS or Windows, SSH into your Linux VPS or homelab server first.