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.
- Keys. If
JWT_SECRET_KEYandCREDENTIAL_ENCRYPTION_KEYare not both in.env, copy them from the running container (docker exec fim-one cat /app/.env) into.envfirst. 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. - 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). - Drop local edits to
docker-compose.ymlanddeploy.sh(git checkout -- docker-compose.yml deploy.sh) so thatgit pullsucceeds and the bundleddeploy.shis used. Movedocker-compose.override.ymlout of the directory: withCOMPOSE_FILEset, compose no longer reads it, and an override that replaces thefim-onevolumes would drop the key store and token mounts if someone added it back toCOMPOSE_FILE. - Coming from the default file (services
postgresandredis): 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, anddeploy.shdoes 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. - Set the
.envvalues above, pull the release, and runDEPLOY_DRY_RUN=1 ./deploy.sh. It must listfim-one,sandboxanddocker-socket-proxyunder “recreating” and nothing else; the database and cache containers are not removed or recreated. - Deploy:
./deploy.sh. The first start hands./dataand./uploadsto uid 10001 (see Security → Upgrading an existing deployment).
Checks after a deploy
docker compose logs docker-socket-proxy shows no refused line for it.