Skip to content
Open
Show file tree
Hide file tree
Changes from 6 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 3 additions & 1 deletion Dockerfile
Original file line number Diff line number Diff line change
@@ -1,12 +1,14 @@
FROM node:20-alpine

RUN apk add --no-cache openssl

RUN npm install -g pnpm

WORKDIR /app

COPY package.json pnpm-lock.yaml ./

RUN pnpm install --frozen-lockfile
RUN pnpm install
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🌐 Web query:

pnpm install --frozen-lockfile behavior lockfile changes documentation

💡 Result:

pnpm install --frozen-lockfile is meant for reproducible installs (especially CI):

  • It will not create or update pnpm-lock.yaml. If pnpm would need to change the lockfile to complete the install, the command fails. [1]
  • It fails if the lockfile is missing (because it’s not allowed to generate one). [1]
  • In CI, this behavior is enabled by default (i.e., frozen-lockfile=true in CI when a lockfile is present), so CI installs will fail if the lockfile would need an update. [1]

What counts as “lockfile needs an update” / why it fails:

  • Most commonly: someone changed a package.json (dependencies/versions/overrides, workspace packages, etc.) but didn’t run pnpm install and commit the updated lockfile, leading to ERR_PNPM_OUTDATED_LOCKFILE. [2]

How to resolve (typical workflow):

  • Locally (or in a non-frozen step), run a normal install to refresh the lockfile, then commit it:
    • pnpm install (or explicitly pnpm install --no-frozen-lockfile) and commit the pnpm-lock.yaml changes. [2]

Sources:
[1] pnpm CLI docs: pnpm install--frozen-lockfile behavior and CI default. (pnpm.cn)
[2] pnpm error docs: ERR_PNPM_OUTDATED_LOCKFILE cause + fix. (pnpm.cn)

Citations:


Use --frozen-lockfile for deterministic container image builds.

At Line 11, pnpm install without --frozen-lockfile can modify the lockfile during builds, breaking reproducibility. Even though pnpm defaults to frozen-lockfile behavior in CI environments with an existing lockfile, Dockerfile builds should explicitly enforce it to prevent dependency resolution drift across rebuilds of the same commit.

Proposed fix
-RUN pnpm install
+RUN pnpm install --frozen-lockfile
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
RUN pnpm install
RUN pnpm install --frozen-lockfile
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@Dockerfile` at line 11, Replace the non-deterministic install step in the
Dockerfile: change the RUN pnpm install invocation to enforce the lockfile by
using the --frozen-lockfile flag (update the RUN pnpm install line to RUN pnpm
install --frozen-lockfile) so the image build fails if the lockfile and manifest
are out of sync.


COPY prisma ./prisma/

Expand Down
41 changes: 41 additions & 0 deletions docker-compose.yml
Original file line number Diff line number Diff line change
Expand Up @@ -12,10 +12,51 @@ services:
- PORT=8020
networks:
- caddy
- tags
labels:
caddy_0: tags.b1.buape.com
caddy_0.reverse_proxy: "{{upstreams 8020}}"

db:
image: postgres:17
restart: always
shm_size: 256mb
environment:
POSTGRES_PASSWORD: ${DB_PASS}
POSTGRES_DB: ${DB_NAME}
POSTGRES_USER: ${DB_USER}
volumes:
- "tags-db:/var/lib/postgresql/data"
networks:
- tags
ports:
- "41006:5432"
Comment on lines +32 to +33
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

Avoid exposing Postgres on all host interfaces by default.

At Line 33, "41006:5432" binds to 0.0.0.0, increasing attack surface. If host access is required, bind to loopback; otherwise keep DB internal to the Docker network.

Safer default
-    ports:
-      - "41006:5432"
+    ports:
+      - "127.0.0.1:41006:5432"
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
ports:
- "41006:5432"
ports:
- "127.0.0.1:41006:5432"
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@docker-compose.yml` around lines 32 - 33, The ports mapping "41006:5432"
exposes Postgres on all host interfaces; change the ports entry for the Postgres
service to either remove the mapping (keep DB internal to the Docker network) or
bind to loopback by replacing it with "127.0.0.1:41006:5432" (or similar
host-only address) in the ports list so it is not exposed to 0.0.0.0.

command: ["postgres", "-c", "log_statement=ddl", "-c", "log_destination=stderr"]

postgres-backup:
image: itbm/postgres-backup-s3
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

🧩 Analysis chain

🏁 Script executed:

# First, let's find and read the docker-compose.yml file
find . -name "docker-compose.yml" -type f

Repository: buape/Tags

Length of output: 74


🏁 Script executed:

# Also search for any docker-compose files
find . -name "docker-compose*" -type f

Repository: buape/Tags

Length of output: 74


🌐 Web query:

itbm/postgres-backup-s3 docker image available tags versions registry

💡 Result:

Registries & image names

  • GitHub Container Registry (GHCR): ghcr.io/itbm/postgresql-backup-s3 (this is where the current images/tags are published). [1]
  • Docker Hub: itbm/postgresql-backup-s3 (older tags exist; Docker Hub page is hard to enumerate from HTML, but specific tag layer pages confirm the repo and tags). [4], [5]
  • The upstream GitHub repo README historically references itbm/postgres-backup-s3 for docker run, but also shows itbm/postgresql-backup-s3 for Kubernetes examples—so you may see both names in the wild. [3]

Available tags / versions (confirmed)

GHCR (ghcr.io/itbm/postgresql-backup-s3)

Recent tags shown by GitHub Packages:

  • latest
  • 1.2.3, 1.2, 1
  • 1.2.2
  • 1.2.1
  • 1.2.0
  • 1.1.1, 1.1 [2]

Source-code release tags in the GitHub repo include (newest → older):

  • v1.2.3, v1.2.2, v1.2.1, v1.2.0, v1.1.1, v1.1.0, v1.0.11, v1.0.10, v1.0.9, v1.0.8, … [6]

Docker Hub (itbm/postgresql-backup-s3)

Tags confirmed to exist (via layer pages):

  • 1.0.8 [4]
  • 1.0.9 [5]

Sources:
[1] [2] GitHub Packages (GHCR) container page for itbm/postgresql-backup-s3 (github.com)
[3] GitHub repo README (itbm/postgresql-backup-s3) (github.com)
[4] Docker Hub layer page for itbm/postgresql-backup-s3:1.0.8 (hub.docker.com)
[5] Docker Hub layer page for itbm/postgresql-backup-s3:1.0.9 (hub.docker.com)
[6] GitHub repo tags list (github.com)

Citations:


🏁 Script executed:

cat -n docker-compose.yml

Repository: buape/Tags

Length of output: 1908


🌐 Web query:

itbm postgresql-backup-s3 GitHub repo S3_REGION environment variable support changelog

💡 Result:

  • Yes — S3_REGION is supported in itbm/postgresql-backup-s3. It’s documented as an environment variable (default us-west-1) in the repo README. [1]
  • Implementation: the backup script maps it to AWS CLI’s region via AWS_DEFAULT_REGION=$S3_REGION. [2]
  • “Changelog” / when it appeared: the repo doesn’t maintain a dedicated CHANGELOG.md or detailed release notes (GitHub release pages don’t show meaningful notes in the HTML view), but S3_REGION support is present at least as far back as tag v1.0.8 (May 24, 2021) in both the README and backup.sh. [3]

Sources:
[1] itbm/postgresql-backup-s3 README (env var table includes S3_REGION default us-west-1) (github.com)
[2] backup.sh on master (export AWS_DEFAULT_REGION=$S3_REGION) (raw.githubusercontent.com)
[3] v1.0.8 tag shows S3_REGION in README and backup.sh (raw.githubusercontent.com)

Citations:


Pin backup image to a specific version tag.

Line 37 uses itbm/postgres-backup-s3 without a tag, defaulting to latest, which is non-reproducible. Use an explicit version such as 1.2.3 or another stable release from the GHCR registry (all recent versions support S3_REGION and the environment variables used here).

Note: Consider updating the image reference to ghcr.io/itbm/postgresql-backup-s3:1.2.3 if using the officially maintained registry.

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@docker-compose.yml` at line 37, The docker-compose service uses an unpinned
image name "itbm/postgres-backup-s3" which defaults to latest; update the image
field to a specific, reproducible tag (for example
"itbm/postgres-backup-s3:1.2.3" or the GHCR variant
"ghcr.io/itbm/postgresql-backup-s3:1.2.3") so the backup service image is
versioned and reproducible; change the image value in the docker-compose entry
where "image: itbm/postgres-backup-s3" appears to include the chosen explicit
tag.

networks:
- tags
depends_on:
- db
environment:
- S3_ACCESS_KEY_ID=${R2_ACCESS_KEY_ID}
- S3_SECRET_ACCESS_KEY=${R2_SECRET_ACCESS_KEY}
- S3_BUCKET=${S3_BUCKET}
- S3_PREFIX=tags
- S3_ENDPOINT=${R2_ENDPOINT}
- S3_REGION=${S3_REGION}
- POSTGRES_DATABASE=${DB_NAME}
- POSTGRES_USER=${DB_USER}
- POSTGRES_PASSWORD=${DB_PASS}
- POSTGRES_HOST=db
- SCHEDULE=@hourly

volumes:
tags-db:

networks:
caddy:
external: true
tags:
external: true