feat(docker): make container socket path configurable for Podman

[esmaeelE]

Summary

docker-compose.yml bind-mounted a hardcoded /var/run/docker.sock into the floci and floci-gcp services. That path only exists when a Docker daemon is running, so on a host with only rootless Podman, podman-compose up fails:

Error: statfs /var/run/docker.sock: no such file or directory
Error: "floci-ui_floci_1" is not a valid container, cannot be used as a dependency

Podman refuses to create a container whose mount source is missing, so floci never gets created and floci-api then fails its depends_on check. Docker instead silently creates an empty directory, which is why this went unnoticed.

This PR reads the path from FLOCI_CONTAINER_SOCKET, defaulting to /var/run/docker.sock so Docker users are unaffected, and documents the Podman override in the README and .env.example.

Type of change

• New feature / service UI (feat:)

Area

• Build / CI / Docker

Verification

Tested on Debian 13 (trixie), Podman 5.4.2 + podman-compose 1.3.0, rootless, no Docker daemon installed.

• podman-compose up -d --build — exit 0; UI :4500 200, API :4501/api/clouds/aws/services 200, Floci :4566 200, storage returns real seeded buckets.
• podman-compose --profile multicloud up -d --build — exit 0; AWS/Azure/GCP/OCI statuses all runtime: reachable; seed job completed ("Multi-cloud seed done"); floci spawned a real postgres:16.3-alpine sidecar through the mounted socket, confirming the API socket is usable.
• pnpm lint, pnpm type-check, pnpm test (1,557 tests), pnpm build — all pass.

Checklist

• pnpm lint, pnpm type-check, pnpm test, and pnpm build pass locally
• No fake/mock data added — unwired states stay empty or show an explicit placeholder
• Commit messages / PR title follow Conventional Commits
• No layout / look-and-feel changes

[greptile-apps]

Confidence Score: 4/5

[Medium risk] Makes container socket path configurable for Podman support.

The PR is not yet safe to merge for rootless Podman because changing the socket path alone may leave the emulator unable to access it.

Findings

1.  Rootless socket may be inaccessible ▶

Summary

The PR makes the host container-socket mount configurable for Podman while retaining Docker’s default path, and documents the override. Since the previous review, it has corrected the README’s description of what happens when the socket is missing.

_{Reviews (2) · Last reviewed commit: "docs(docker): fix Podman section contrad..."}

[greptile-apps]

Rootless socket may be inaccessible If the host user's Podman socket does not permit access by the Floci runtime, which runs as UID 1001, changing the mount source alone will not let Floci connect to it. The stack can start, but Lambda invocations will still fail to start containers. The Podman setup needs to account for socket access as well as its path.

[fredpena]

Thank you, @esmaeelE, for tracking this down and for including the exact Podman error.

(blocking) The last sentence of the new Podman section ("Without it the emulator still starts...") contradicts the paragraph above it, which says podman-compose up fails when the default socket is missing. Would you reword it to describe that create error?

(follow-up, in this PR if you are willing) The description still has the empty template. A line in Verification naming your Podman version and what you ran would help the next Podman user.

(follow-up, separate PR) Rootless socket access and host prerequisites are tracked in #293.

No blockers from my side.

[esmaeelE]

Thanks for the review. Two follow-ups addressed:

1. Blocking: The closing sentence of the Podman section now describes the actual failure instead of saying the emulator still starts. See commit b2543ee — it now reads that Podman never creates the floci container, up aborts with the statfs error, and floci-api fails its depends_on check.

2. PR template: Filled in the empty description, including a Verification section naming the stack involved (Podman 5.4.2 + podman-compose 1.3.0, rootless, no Docker daemon) and what was run.

Leaving the rootless-socket-access thread for #293 / a separate PR as you suggested.