Skip to content

Merge infra changes to main #39

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
buapebot wants to merge 7 commits into
base: main
Choose a base branch
from
Open

Merge infra changes to main #39

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
31b3b64
fix: lockfile error
Asleep123 Oct 26, 2025
e976a8c
add db to compose
Asleep123 Oct 26, 2025
fdfe909
add tags network
Asleep123 Oct 26, 2025
46d1264
change db version
Asleep123 Oct 26, 2025
6f52ff9
install openssl i guess
Asleep123 Oct 26, 2025
8217717
chore: use env vars for S3_BUCKET and S3_REGION
buapebot Feb 25, 2026
ec1dbe2
chore: rename R2 vars to S3 naming convention
buapebot Feb 25, 2026
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
View file
Open in desktop
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

@coderabbitai coderabbitai bot Feb 25, 2026

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
View file
Open in desktop
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

@coderabbitai coderabbitai bot Feb 25, 2026

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

@coderabbitai coderabbitai bot Feb 25, 2026

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=${S3_KEY}
- S3_SECRET_ACCESS_KEY=${S3_PASS}
- S3_BUCKET=${S3_BUCKET}
- S3_PREFIX=tags
- S3_ENDPOINT=${S3_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