Set up and update an existing installation.

Before you start

Everything below runs on macOS or Linux. Check you have all five:

• A machine you control, with Docker and Docker Compose. Compose is the topology this installer ships; cloud targets are configured from the OpenTofu modules inside the release.
• curl, tar, jq, and shasum (or sha256sum). All but jq ship with macOS and every mainstream Linux; jq is one brew install jq or apt install jq away. The installer checks for all of them first and stops with a clear message if one is missing.
• Outbound HTTPS to github.com and ghcr.io. The installer fetches its tools from the first and the release from the second, and verifies the release signature against Sigstore's public services.
• Your install token. Every installation gets its own. It is the only credential involved, and it is what fetches releases.
• A name for this installation, such as Acme Production. This is required, shows up on the Admin Updates screen, and is capped at 120 characters with no = or |.

Install

export THINQOS_INSTALL_TOKEN=your-token-here
export THINQOS_INSTALL_NAME='Acme Production'

curl -fsSL https://thinqos.com/install.sh | bash

curl -fsSLO https://thinqos.com/install.sh
curl -fsSL https://thinqos.com/install.sh.sha256 | shasum -a 256 -c -
less install.sh
bash install.sh

cd thinqos/compose
docker compose --env-file .env up -d

Options

Everything above works with no flags at all. These are here when you need them:

bash install.sh --help    # the full list, straight from the script

What the installer actually does

It is a trust-establishing script, and it earns the right to be piped into a shell by refusing anything it cannot prove. In order:

Updating

Re-run the installer against the same directory. It fetches the newest release on your channel, verifies the signature exactly as it did the first time, and re-pins the image, leaving every value you set in .env untouched. Then recreate the stack.

export THINQOS_INSTALL_TOKEN=your-token-here
export THINQOS_INSTALL_NAME='Acme Production'
curl -fsSL https://thinqos.com/install.sh | bash -s -- --dir /path/to/thinqos
cd /path/to/thinqos/compose && docker compose --env-file .env up -d

Cloud installs run this on a schedule instead, and every step is gated: the signature is verified, database changes run first, a new copy starts serving no traffic until it passes a health check, and only then does traffic move. If any step fails, the version you were already running keeps serving.

Inside thinqOS, under Admin, an Updates screen shows the version you are on, every update your install has attempted and what came of it, and three settings you control: whether updates install automatically, which lane you follow, and an optional window of hours during which updates may land. Turn automatic updates off and nothing installs until you turn them back on.

What your install reports back

In exchange for updates, your install reports a small, fixed set of facts about itself: which version it is on, whether its last few updates succeeded, whether its database is healthy, how fresh its reference data is, where it is deployed, and roughly how many seats it has, in broad bands.

It never sends your content. No messages, no prompts, no documents, no file names, and nothing identifying your users. You can see the exact payload on the Updates screen every time it is sent.

When something goes wrong