Install

curl -fsSL https://warmbly.com/install.sh | sh

No clone, no compiler, no toolchain. The script checks Docker, creates one directory, generates every secret, pulls the pinned release images, starts the stack and prints the link that claims your instance. On a clean box with Docker already installed it finishes in under two minutes.

Add --wizard and it asks the questions a config reference cannot ask for you.

curl -fsSL https://warmbly.com/install.sh | sh -s -- --wizard

What it installs

Nothing is built on your machine. The clone-and-build path still exists and is still supported; see self-hosting for when you want it.

Before you run it

Piping a script into a shell is a fair thing to be uneasy about, and the objection is only answerable if the script is versioned, inspectable and checksummed. All three are:

curl -fsSLO https://warmbly.com/install.sh
curl -fsSLO https://warmbly.com/install.sh.sha256
sha256sum -c install.sh.sha256
less install.sh
sh install.sh

The script itself is written to deserve that: set -eu, every line inside a function, and main "$@" on the very last line, so a download that is cut off half way executes nothing at all. It never asks to be piped into sudo; it asks for elevation only for the specific steps that need it, and names them.

You also do not have to run it to see what it would do:

sh install.sh --dry-run

That prints the exact .env and compose file it would write, and touches nothing.

And after it runs

Every release publishes an images.json asset listing the manifest digest of each image in it. Once the pull finishes the installer compares what actually landed on the machine against that file, and stops before starting anything if they differ. You can check the same thing yourself at any time:

docker image inspect ghcr.io/warmbly/warmbly/backend:v1.4.2 --format '{{index .RepoDigests 0}}'

An install pointed at your own registry with --registry has no manifest to check against, and the installer says so rather than pretending it verified something.

Requirements

Port 3000 is the one that actually collides: it is the default for a lot of other self-hosted software. The installer checks every port before it writes anything and tells you which one is taken.

The wizard

--wizard walks nine steps. Every answer has a default that matches the fast path, so pressing enter through the whole thing produces exactly the install the one-liner produces.

Every menu takes the keys you already use:

The review screen at the end takes enter to install, e to go back into a section, and q to quit.

Steps append rather than replacing each other, so the whole run stays scrollable and nothing above the installer is touched. --clear redraws the screen at each step instead, if you prefer that.

app.example.com     admin.example.com    api.example.com
ws.example.com      track.example.com    forms.example.com

See it first

curl -fsSL https://warmbly.com/install.sh | sh -s -- --demo

The real wizard and the real review, with the pull, the container creation and the health wait played rather than run. It writes no file, pulls no image, creates no container and needs no Docker, so it answers "what does this actually do" without a server to try it on.

It takes about half a minute, paced so the phases are readable; a real install is several minutes, most of it the pull and the first boot's migrations. WARMBLY_DEMO_FAST=1 collapses it to under ten seconds. From a checkout: make installer-demo.

For agents

An agent should never drive the wizard: it reads raw keypresses and needs a terminal. Every answer is also a flag, so --yes with flags is silent, deterministic and idempotent, and --print-env and --dry-run show what a run would produce without producing it.

The repository ships a warmbly-install skill under skills/ covering exactly that, plus backups and moving an instance. Install it the way your agent expects, for example cp -r skills/warmbly-install ~/.claude/skills/.

Unattended

Every answer is a flag and a WARMBLY_* environment variable, so the same script provisions from Ansible or cloud-init:

curl -fsSL https://warmbly.com/install.sh | sh -s -- --yes \
  --dir /opt/warmbly \
  --host warmbly.acme.com \
  --tls caddy \
  --data-root /mnt/data/warmbly \
  --blobs s3 \
  --retention-preset minimal \
  --backup-dir /mnt/backups/warmbly \
  --version v1.4.2

--print-env emits the .env and exits. --dry-run prints every file it would write and exits. --demo walks the whole thing and installs nothing.

Re-running it

The installer is idempotent. A second run:

• adopts the existing .env and never regenerates a secret, because a new AUTH_SECRET signs everyone out and a new CREDENTIALS_ENCRYPTION_KEY is permanent data loss
• keeps the existing data root, because pointing an install at a new path is not a move, it is an empty instance next to a full one
• keeps any keys you added to .env yourself, in a clearly marked block at the end
• regenerates docker-compose.yml, keeping the previous one as docker-compose.yml.bak
• refuses a directory it did not create, unless you pass --force

Put your own compose changes in a docker-compose.override.yml, which compose merges on top and the installer never touches.

Updating

The version pill in the admin panel, then Update and restart. On an install created this way the updater runs in image mode: it writes the new tag into .env, pulls, and recreates the containers whose image changed. Nothing is built. See updates.

By hand, from the install directory:

docker compose -p warmbly pull && docker compose -p warmbly up -d

Removing it

sh install.sh --uninstall

Stops and removes the containers and leaves every byte of data where it is. Adding --purge-data deletes the data root and the install directory as well, and asks you to type a phrase first, because that also destroys the only keys that could have opened a backup of it.

When it goes wrong

More in troubleshooting and instance health.

Next

• First run: claiming the instance, the first owner, demo data
• Data control: where every store lives, what each retention window governs, backups, and moving an instance
• Configuration: every environment variable and every database-backed setting
• Self-hosting: the full guide, including building from source