Conversation
Updated PostgreSQL and Neo4j service configurations to use env_file for environment variables and added resource limits and health checks.
WalkthroughThe pull request introduces production-ready infrastructure configuration by adding environment variable management through a .env file, enhancing Docker Compose services with resource constraints and health monitoring, and modernizing the Dockerfile with Python 3.11-slim base image, uv-based dependency management, and supervisor process control. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Tip Try Coding Plans. Let us write the prompt for your AI agent so you can ship faster (with fewer bugs). Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
|
access restricted to sonarqube |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🧹 Nitpick comments (1)
compose.yaml (1)
22-22: Use configured Postgres user in healthcheck instead of hardcodingpostgres.If
POSTGRES_USERchanges in.env, the current probe can fail even when DB is healthy.Suggested fix
- test: ["CMD-SHELL", "pg_isready -U postgres"] + test: ["CMD-SHELL", "pg_isready -U $${POSTGRES_USER} -d $${POSTGRES_DB}"]🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@compose.yaml` at line 22, Replace the hardcoded Postgres user in the healthcheck command with the configured environment variable; update the compose.yaml healthcheck "test" entry that currently runs "pg_isready -U postgres" to use the POSTGRES_USER substitution (e.g. pg_isready -U ${POSTGRES_USER}) so the probe uses the same user from the environment, and ensure the service's environment/ .env provides POSTGRES_USER.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.env:
- Around line 1-4: The committed .env contains real secrets (POSTGRES_USER,
POSTGRES_PASSWORD, POSTGRES_DB, NEO4J_AUTH); remove the tracked .env from the
repo, add it to .gitignore, create a sanitized .env.example with placeholder
values for POSTGRES_USER/POSTGRES_PASSWORD/POSTGRES_DB/NEO4J_AUTH, and ensure
real credentials are injected at runtime via your secrets manager/CI/CD (and
rotate the exposed credentials if they were already used).
In `@compose.yaml`:
- Around line 30-33: The compose YAML has mis-indentation for the environment
block; move the environment key to the same indentation level as env_file and
ensure its value is a properly indented mapping or list entry for
NEO4JLABS_PLUGINS (so the NEO4JLABS_PLUGINS entry is aligned under environment
and uses valid YAML string/array syntax), e.g. correct the placement of the
environment key and align the NEO4JLABS_PLUGINS value so the parser accepts it.
- Line 3: Replace all uses of floating "latest" images with explicit,
reproducible tags (and optionally digests). In the compose file update the image
entries referenced as "image: postgres:latest", "image: neo4j:latest", and
"image: redis:latest" to pinned versions that include the major version and OS
distro (e.g., postgres:17.8-bookworm, neo4j:2026.01.3-trixie,
redis:8.4.0-bookworm) and, for stronger immutability, append the corresponding
`@sha256`:<digest> for each image.
In `@dockerfile`:
- Around line 37-38: The Dockerfile uses the COPY . . instruction which will
include sensitive files like .env in the image; create a .dockerignore at the
repository root that lists at minimum ".env" to exclude secrets from the build
context, keep .env.example tracked for docs, and ensure the .dockerignore is
committed so the Dockerfile's COPY . . no longer copies .env into the image.
---
Nitpick comments:
In `@compose.yaml`:
- Line 22: Replace the hardcoded Postgres user in the healthcheck command with
the configured environment variable; update the compose.yaml healthcheck "test"
entry that currently runs "pg_isready -U postgres" to use the POSTGRES_USER
substitution (e.g. pg_isready -U ${POSTGRES_USER}) so the probe uses the same
user from the environment, and ensure the service's environment/ .env provides
POSTGRES_USER.
| POSTGRES_USER=postgres | ||
| POSTGRES_PASSWORD=yoursecurepassword | ||
| POSTGRES_DB=momentum | ||
| NEO4J_AUTH=neo4j/yoursecurepassword |
There was a problem hiding this comment.
Do not store runtime credentials in a tracked .env file.
Committing .env in-repo creates a credential-leak path (git history, forks, and accidental image inclusion). Keep only a sanitized .env.example in git, and inject real secrets at deploy/runtime.
🧰 Tools
🪛 dotenv-linter (4.0.0)
[warning] 2-2: [UnorderedKey] The POSTGRES_PASSWORD key should go before the POSTGRES_USER key
(UnorderedKey)
[warning] 3-3: [UnorderedKey] The POSTGRES_DB key should go before the POSTGRES_PASSWORD key
(UnorderedKey)
[warning] 4-4: [UnorderedKey] The NEO4J_AUTH key should go before the POSTGRES_DB key
(UnorderedKey)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.env around lines 1 - 4, The committed .env contains real secrets
(POSTGRES_USER, POSTGRES_PASSWORD, POSTGRES_DB, NEO4J_AUTH); remove the tracked
.env from the repo, add it to .gitignore, create a sanitized .env.example with
placeholder values for POSTGRES_USER/POSTGRES_PASSWORD/POSTGRES_DB/NEO4J_AUTH,
and ensure real credentials are injected at runtime via your secrets
manager/CI/CD (and rotate the exposed credentials if they were already used).
| @@ -2,16 +2,22 @@ services: | |||
| postgres: | |||
| image: postgres:latest | |||
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
git ls-files | grep -E '(compose|docker)' | head -20Repository: potpie-ai/potpie
Length of output: 185
🏁 Script executed:
cat -n compose.yamlRepository: potpie-ai/potpie
Length of output: 2569
🌐 Web query:
Docker image pinning best practices PostgreSQL Neo4j Redis 2025 2026 production
💡 Result:
Production Docker image pinning (2025–2026): what to do
1) Prefer immutable digests for what actually runs in prod
- Use
@sha256:...in Kubernetes/Compose/Swarm so the deployed image cannot change under the same tag. Docker explicitly recommends digest pinning to guarantee the exact image you tested (even if a publisher later moves a tag). [1] - You can enforce this with policy (for example, “reject tag-only references”). [2]
- Practical pattern: keep both for readability:
postgres:17.8-bookworm@sha256:...(humans see the version; machines enforce immutability). [1][8]
2) Avoid floating tags (latest, 17, 8, enterprise, etc.) in prod
Floating tags can drift and silently introduce changes (security, OS, libc, tooling), breaking reproducibility and upgrade safety. Digest pinning eliminates this class of surprise. [1][8]
3) For stateful databases, pin (a) DB version and (b) base OS variant
Even if you don’t use digests, pinning the distro/suite reduces surprise OS jumps:
- PostgreSQL: Docker Hub publishes both
*-bookwormand*-trixievariants (and Alpine variants). [4] Real-world incidents have occurred where upgrading a Postgres minor image tag effectively pulled in a major Debian bump unless the suite was explicitly pinned (example cited:17.6-bookwormstyle). [5] - Redis: The Redis image docs explicitly call out that Debian suite tags (e.g.,
bookworm,trixie) indicate the Debian base, and recommend specifying them explicitly to “minimize breakage” when Debian releases change—especially if you install extra packages. [6] - Neo4j: Neo4j publishes versioned tags and also OS/base suffixes (e.g.,
-trixie,-bullseye,-ubi9,-ubi10), and notes the default base can change across releases (e.g., starting with 2026.01). [3]
4) Choose the right “pin depth” for your environment
- Highest assurance (most common for regulated / critical prod): deploy by digest. [1][2][8]
- Balanced (still stable, easier ops): pin to patch + OS suite, then periodically roll forward intentionally, e.g.
postgres:17.8-bookworm/redis:8.4.0-bookworm/neo4j:2026.01.3-trixie. [3][4][6] - If you operate Postgres on Kubernetes, projects like CloudNativePG still recommend digest as the most reliable reference, with a “minor-version rolling tag” as a compromise. [7]
5) Make updates intentional (don’t “auto-drift”)
Have an explicit workflow: periodic rebuild/update PRs (Renovate/Dependabot), vulnerability scanning gates, staging soak, then promote the tested digest into production. Digest pinning supports that promotion model cleanly. [1][2][8]
Source key: [1]=Docker Dockerfile best practices, [2]=Docker image validation policies, [3]=Neo4j Docker ops manual, [4]=Postgres Docker Hub tags, [5]=Vonng analysis of Postgres image OS drift, [6]=Redis Docker Hub docs, [7]=CloudNativePG postgres-containers tags/recommendation, [8]=Red Hat guidance on digests.
Pin explicit versions (with OS distro) instead of :latest for all stateful services.
Using postgres:latest, neo4j:latest, and redis:latest makes deploys non-reproducible. Recommended approach: pin version + base OS distro (e.g., postgres:17.8-bookworm, redis:8.4.0-bookworm, neo4j:2026.01.3-trixie). For highest assurance, also pin digests (e.g., postgres:17.8-bookworm@sha256:...).
Applies to: lines 3, 28, 59
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@compose.yaml` at line 3, Replace all uses of floating "latest" images with
explicit, reproducible tags (and optionally digests). In the compose file update
the image entries referenced as "image: postgres:latest", "image: neo4j:latest",
and "image: redis:latest" to pinned versions that include the major version and
OS distro (e.g., postgres:17.8-bookworm, neo4j:2026.01.3-trixie,
redis:8.4.0-bookworm) and, for stronger immutability, append the corresponding
`@sha256`:<digest> for each image.
| env_file: | ||
| - .env | ||
| environment: | ||
| NEO4JLABS_PLUGINS: '["apoc"]' # Add this line to include APOC plugin |
There was a problem hiding this comment.
Fix Neo4j YAML indentation (currently invalid syntax).
Line 32 is mis-indented, which breaks YAML parsing.
Suggested fix
neo4j:
image: neo4j:latest
container_name: potpie_neo4j
env_file:
- - .env
- environment:
+ - .env
+ environment:
NEO4JLABS_PLUGINS: '["apoc"]' # Add this line to include APOC plugin
NEO4J_dbms_security_procedures_unrestricted: "apoc.*" # Allow APOC procedures
NEO4J_dbms_memory_transaction_total_max: 0🧰 Tools
🪛 YAMLlint (1.38.0)
[error] 32-32: syntax error: expected , but found ''
(syntax)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@compose.yaml` around lines 30 - 33, The compose YAML has mis-indentation for
the environment block; move the environment key to the same indentation level as
env_file and ensure its value is a properly indented mapping or list entry for
NEO4JLABS_PLUGINS (so the NEO4JLABS_PLUGINS entry is aligned under environment
and uses valid YAML string/array syntax), e.g. correct the placement of the
environment key and align the NEO4JLABS_PLUGINS value so the parser accepts it.
| # Copy application code | ||
| COPY . . |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== Locate .dockerignore =="
fd -HI '^\.dockerignore$' .
DOCKERIGNORE="$(fd -HI '^\.dockerignore$' . | head -n1 || true)"
if [ -n "${DOCKERIGNORE}" ]; then
echo "== Check ignore rules related to .env =="
rg -n '(^|/)\.env(\*|$)|^\!\.env\.example$' "${DOCKERIGNORE}" || true
else
echo "No .dockerignore found"
fi
echo "== Confirm blanket copy instructions =="
fd -HI '^(dockerfile|Dockerfile)$' . | xargs -I{} rg -n '^\s*COPY\s+\.\s+\.' {}Repository: potpie-ai/potpie
Length of output: 161
Create .dockerignore to prevent .env secrets from being copied into the image.
The repository has no .dockerignore file, so the COPY . . instruction on line 38 will copy all files from the build context into the Docker image—including .env if it exists. Add a .dockerignore file at the repository root with at least:
.env
Keep .env.example tracked in version control for documentation, but ensure .env with actual secrets is excluded.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@dockerfile` around lines 37 - 38, The Dockerfile uses the COPY . .
instruction which will include sensitive files like .env in the image; create a
.dockerignore at the repository root that lists at minimum ".env" to exclude
secrets from the build context, keep .env.example tracked for docs, and ensure
the .dockerignore is committed so the Dockerfile's COPY . . no longer copies
.env into the image.
1 participant
Summary by CodeRabbit
Release Notes