Maintenance

Day-to-day operation once the stack is running.

Updating

If you installed TypeType with the recommended installer, run it again. It updates the managed stack files, preserves .env, Compose overrides, and the data volumes, pulls the release images, waits for the services, verifies the component versions, and provisions any newly added Garage resources:

curl -fsSL https://raw.githubusercontent.com/TypeType-Video/TypeType/main/scripts/install-stack.sh | bash -s -- --yes
cd ~/typetype-stack
docker compose ps

Configured ports remain unchanged when the installer is run again. Accounts, history, downloads, and service secrets remain in .env and the named volumes. Before changing managed files, the installer creates a timestamped directory under .typetype-backups/ containing the previous stack files and, when the old configuration is valid, its resolved and running image references.

For a script-free installation, first replace the Compose file and scripts with the current release while keeping .env, any override, and custom configuration. Then validate and recreate the stack:

docker compose config -q
docker compose pull
docker compose up -d --force-recreate --wait --wait-timeout 180
docker compose ps

Migrate an older Priveetee stack

Older installations may still use Compose files that reference ghcr.io/priveetee/.... Running docker compose pull with those files continues to pull the old image namespace; it does not move the instance to a current ghcr.io/typetype-video/... release.

Check the resolved image names from the directory that contains the active Compose file:

docker compose config --images

If any TypeType image starts with ghcr.io/priveetee/, refresh the stack files once. First keep the current configuration and a database backup:

cd /path/to/your/typetype-stack
migration_backup="../typetype-stack-before-migration-$(date +%Y%m%d-%H%M%S)"
mkdir -p "$migration_backup"
cp -a .env docker-compose.yml "$migration_backup"/
[ ! -f nginx.conf ] || cp -a nginx.conf "$migration_backup"/
[ ! -f garage.toml ] || cp -a garage.toml "$migration_backup"/
docker compose exec -T postgres \
  pg_dump -U typetype typetype > "$migration_backup/typetype.sql"

Download the current supported Compose file and scripts into the same directory. The installer keeps the existing .env file, Compose override, unmanaged files, and named volumes while adding current required entries:

curl -fsSL https://raw.githubusercontent.com/TypeType-Video/TypeType/main/scripts/install-stack.sh \
  | bash -s -- --dir "$PWD" --download-only --yes

Custom stack files are replaced

The command refreshes docker-compose.yml, .env.example, and the stack scripts. Compare the timestamped backup before restoring a custom change; do not copy the old Compose file back, because that would also restore its old image references. Keep custom service changes in docker-compose.override.yml.

An old host nginx.conf is backed up but is no longer mounted by the default stack, because nginx now ships in the web image. An old garage.toml is staged for a one-time import into the garage_config volume. The initializer never overwrites a configuration that is already present in that volume.

Validate the refreshed stack and inspect the images again:

docker compose config -q
docker compose config --images

The four TypeType application images must now start with ghcr.io/typetype-video/. Pull them and recreate the services without deleting volumes:

docker compose pull
docker compose up -d --force-recreate --wait --wait-timeout 180
docker compose ps

Finally, replace the example origin below with the instance URL and confirm the deployed component revisions:

curl -fsS https://watch.example.com/api/version
curl -fsS https://watch.example.com/api/version/web
curl -fsS https://watch.example.com/api/version/server
curl -fsS https://watch.example.com/api/version/token
curl -fsS https://watch.example.com/api/version/downloader

This one-time migration gap was made clear by filippobaroni's follow-up in discussion #133.

When upgrading from a release that did not include Garage, complete the manual setup, including Part 2, once before using downloads.

Before every update, keep the current image references and a database backup so you can roll back the update if necessary.

Logs

docker compose logs -f typetype-server     # follow one service
docker compose logs --tail=100 typetype    # last 100 lines of the web app
docker compose logs                         # everything

The server logs are the place to look when extraction, accounts, or the API misbehave.

Backups

Two stores hold everything that matters: the database and the object store.

Database

docker compose exec -T postgres \
  pg_dump -U typetype typetype > typetype-$(date +%F).sql

Restore into a fresh stack:

cat typetype-YYYY-MM-DD.sql | docker compose exec -T postgres psql -U typetype typetype

Object store (downloads)

The downloads are in the garage_data and garage_meta volumes. Back up the volumes themselves (stop the stack first for a consistent copy):

docker compose down
docker run --rm -v typetype_garage_data:/data -v "$PWD":/backup busybox \
  tar czf /backup/garage-data-$(date +%F).tar.gz -C /data .
docker compose up -d

Adjust the volume name if your Compose project prefix differs (see it with docker volume ls).

TIP

Downloads are regenerable artifacts, so the database backup is the important one. The .env file is also worth keeping, since it pins your ports and any custom values.

Stopping and starting

docker compose stop      # stop containers, keep them
docker compose start     # start them again
docker compose down      # remove containers, keep volumes (data safe)

Resources

A small instance is comfortable on ~2 GB of RAM. The heaviest components are the API server (JVM) and the database. The downloader does the most disk and network work while jobs run; it is idle otherwise.