Passer au contenu principal
docker-compose.prod.yml is a second, self-contained compose file for hosts where the reverse proxy (Caddy, Nginx, Traefik) runs as a container of another compose project and reaches FIM One over a Docker network that both projects join. Use it instead of docker-compose.yml, not as an overlay.

​
When to use it

Everything else is the same as the default file: the application runs unprivileged and without the Docker socket, sandboxes are started by the docker-socket-proxy service, generated keys are kept in the app_secrets volume at /var/lib/fim-one/secrets. See Security → Code execution and the Docker socket. Only the fim-one service joins the shared network. The database, the cache and the sandbox proxy stay on the project’s own network, so other stacks on the shared network cannot reach them. The application addresses them by container name; container names are unique on a host, so a service of another stack on the shared network with a generic name such as postgres cannot answer in their place.

​
Settings in .env

COMPOSE_FILE in .env makes plain docker compose … commands and ./deploy.sh use this file in this directory. Optional: DOCKER_HOST_DATA_DIR (host path of ./data, default $PWD/data), and the variables in Environment Variables → Code execution. Point the reverse proxy at fim-one:3000 (the frontend; it proxies /api/*). Point it at fim-one:8000 as well only if it sends SSE streams to the API directly. Keys: with both keys in .env the key store stays empty and nothing is generated. Without them, a first start (empty database) generates them into the app_secrets volume; back that volume up with ./data.

​
New installation

​
Switching an existing deployment (one time)

The volumes of a compose project are named <project>_<volume>; the project name is the checkout directory’s name unless COMPOSE_PROJECT_NAME says otherwise. Switch in the same directory, with the same project name, and the existing postgres_data, redis_data, ./data and ./uploads are reused. Check before and after: docker volume ls | grep _postgres_data and the volumes: section of docker compose config.
  1. Keys. If JWT_SECRET_KEY and CREDENTIAL_ENCRYPTION_KEY are not both in .env, copy them from the running container (docker exec fim-one cat /app/.env) into .env first. Older images generated missing keys inside the container, and they are gone when it is replaced. The new image refuses to start on a database with data when a key is missing, rather than generating a new one.
  2. Back up the database (docker exec <db container> pg_dump -U fim -d fim_one -Fc > fim_one.dump), .env, and any local changes to tracked files (git diff > local.diff).
  3. Drop local edits to docker-compose.yml and deploy.sh (git checkout -- docker-compose.yml deploy.sh) so that git pull succeeds and the bundled deploy.sh is used. Move docker-compose.override.yml out of the directory: with COMPOSE_FILE set, compose no longer reads it, and an override that replaces the fim-one volumes would drop the key store and token mounts if someone added it back to COMPOSE_FILE.
  4. Coming from the default file (services postgres and redis): stop and remove those two containers before the first deploy (docker compose -f docker-compose.yml rm -s -f postgres redis). The new services use the same volumes, and deploy.sh does not remove containers of services the file in use does not list, so the old database container would otherwise keep running on the same data directory.
  5. Set the .env values above, pull the release, and run DEPLOY_DRY_RUN=1 ./deploy.sh. It must list fim-one, sandbox and docker-socket-proxy under “recreating” and nothing else; the database and cache containers are not removed or recreated.
  6. Deploy: ./deploy.sh. The first start hands ./data and ./uploads to uid 10001 (see Security → Upgrading an existing deployment).

​
Checks after a deploy

Then run a chat that uses a code tool and check that docker compose logs docker-socket-proxy shows no refused line for it.