Finalization

First start: populate the application directory

docker compose up -d ktdocker
sleep 5

The application is not expected to come up on this run

This start exists to populate rw/. The container’s own start script creates the symlinks into /ro (rw/bin, rw/lisp, rw/xin, rw/etc), creates var/, www/ and recovery/, writes rw/var/secret — and only then tries to launch the service. The database has not been activated yet, so the service itself may not become available.

That is expected at this point. What matters is that rw/ got populated.

rw/bin/cms.sh does not exist before this run, which is why the commands in the next sections cannot come first.

Check that the directory was populated:

ls -l rw/bin rw/lisp rw/xin rw/etc rw/var/secret

If rw/bin does not appear

Check docker compose logs ktdocker. The usual causes are rw/ not being owned by UID 1234, or a wrong path in the bind mount.

Stop it again

docker compose stop ktdocker

restart: unless-stopped restarts the container on every exit, with an exponentially increasing delay but without ever giving up. Left alone it would keep flapping through the next steps — filling the log and, in the worst case, letting a half-started application touch the database while /finish-installation is working on it.

An explicit stop is the one thing that policy honours: this is what distinguishes unless-stopped from always. The container stays down until you bring it up at the end.

Activate the database

/finish-installation populates the _ktbsversion table that pg.sql created, which is what makes the schema usable for this application version.

docker compose --profile tools run --rm cms /finish-installation

The command runs in a separate container with the same image and mounts, so it works whether or not the application container is currently up.

No separate /write-secret-file needed

The container’s start script already wrote rw/var/secret during the first start, guarded by the same check. Only if the file is missing above, create it explicitly:

docker compose --profile tools run --rm cms /write-secret-file

Install a disk pool

Large files are stored on disk instead of in the database. This is strongly recommended for performance.

docker compose --profile tools run --rm cms \
  /make-disk-pool default /rwshared/pool/

Run this only once

/make-disk-pool fails if a pool with that name is already registered. That is expected on a second run, not an error to fix.

Create the first user

source ./rap.config.sh
docker compose --profile tools run --rm -it cms \
  /reset-administrator "$ADMIN_EMAIL"

You are prompted for a password. The same command serves later on: with a known address it resets that user’s password, with a new one it creates a further administrator. Either way the account gets administrator rights, and the command reports which of the two it did.

Start everything

Now bring both services up — this is the first start that is expected to succeed:

docker compose up -d
docker compose ps

Both services must reach state healthy. ktdocker may need up to two minutes for its first health check — that is the configured start_period.

Verify

source ./rap.config.sh

# Directly against the container
curl -s "http://127.0.0.1:8080/$PREFIX/" | grep __ac_password

A hit on __ac_password means the login page is being served and the installation succeeded.

Once your reverse proxy is in place, check it from outside as well:

curl -s "https://$PREFIX.$DOMAIN/$PREFIX/" | grep __ac_password

Or simply open the URL in a browser and log in with the administrator account you just created.

Next steps

• Configure the AI Middleware with your LLM provider
• Set up the reverse proxy and backups, see Maintenance