please add docker image github action 🙏🏻

[Karelak]

Description

Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context.
generated docker image using dockerfile so it automatically for free makes a docker image to pull from instead of having to build it on the host that will deploy it even though theres always a choice i just want to have up to date version on server

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update

[Karelak]

also can u please make the simple-proxy package public too idk why it would be private but if you have ur reasons then whatever.
heres how to make it public:
Go to your GitHub profile → Packages tab
Or directly: https://github.com/p-stream/simple-proxy/?tab=packages
Find simple-proxy package
Click on it → Package settings (right side)
Scroll to Danger Zone → Change visibility → Public

[Duplicake-fyi]

also can u please make the simple-proxy package public too idk why it would be private but if you have ur reasons then whatever. heres how to make it public: Go to your GitHub profile → Packages tab Or directly: https://github.com/p-stream/simple-proxy/?tab=packages Find simple-proxy package Click on it → Package settings (right side) Scroll to Danger Zone → Change visibility → Public

I can't see a package (and I have access to the organization) so I don't think we have one on github

[Duplicake-fyi]

/agentic_review

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (2) 📘 Rule violations (1) 📎 Requirement gaps (0)

1. Hardcoded DATABASE_URL credentials 📘 Rule violation ⛨ Security

Description

The workflow hardcodes a database connection string containing credentials in build-args, which
can leak secrets via CI logs and Docker image metadata/history. This violates security-first
handling of sensitive data.

Code

.github/workflows/docker-publish.yml[R66-67]

+        build-args: |
+          DATABASE_URL=postgresql://user:password@localhost:5432/db

Evidence

Compliance requires sensitive data (passwords/tokens/keys) not be exposed in code or mishandled; the
workflow includes a plaintext user:password in DATABASE_URL passed into the Docker build.

Rule 6: Generic: Security-First Input Validation and Data Handling
.github/workflows/docker-publish.yml[66-67]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The GitHub Actions workflow passes a hardcoded `DATABASE_URL` containing plaintext credentials (`user:password`) to the Docker build via `build-args`, which risks secret exposure (CI logs and image history/metadata).

## Issue Context
This workflow builds and publishes an image to GHCR; build arguments can be visible during build and can become discoverable depending on how they are used in the Dockerfile.

## Fix Focus Areas
- .github/workflows/docker-publish.yml[66-67]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Version tag retargeted 🐞 Bug ⛯ Reliability

Description

The workflow tags every master build with the package.json version, so if the version isn’t bumped
on each commit, the same version tag will be overwritten to point at different images over time.
This breaks reproducibility and makes rollbacks/debugging unreliable (pulling 2.1.3 on different
days yields different binaries).

Code

.github/workflows/docker-publish.yml[R46-51]

+        tags: |
+          # Set latest tag for master branch
+          type=raw,value=latest,enable={{is_default_branch}}
+          # Use version from package.json
+          type=raw,value=${{ steps.package-version.outputs.version }}
+          # Use short SHA

Evidence

The workflow always emits a raw tag equal to the package.json version, and package.json has a
single version value. Since the workflow runs on every push to master, that version tag is
re-pushed repeatedly unless the version is bumped each time.

.github/workflows/docker-publish.yml[3-8]
.github/workflows/docker-publish.yml[41-54]
package.json[1-8]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The workflow publishes a Docker tag equal to `package.json`'s version on every push to `master`, which can overwrite the same version tag to point at different images.

### Issue Context
`package.json` typically changes less frequently than commits to `master`, so `2.1.3` (example) would be re-pushed and no longer uniquely identify a build.

### Fix Focus Areas
- .github/workflows/docker-publish.yml[41-54]

### Suggested change
- Gate the raw `package.json` version tag so it is only emitted for tag builds (or remove it entirely and rely on `type=ref,event=tag`). For example, change the version tag line to use an enable condition for tag events (per `docker/metadata-action` syntax), or switch to `type=semver` driven by git tags.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. Arm64 build instability risk 🐞 Bug ⛯ Reliability

Description

The workflow builds multi-arch (linux/amd64,linux/arm64) while the Dockerfile executes multiple
build-time commands (npm install, prisma generate, npm run build). This can be brittle for
arm64 builds (native deps/engines), so you should validate arm64 builds explicitly and consider
adding an explicit QEMU setup step or narrowing platforms until confirmed stable.

Code

.github/workflows/docker-publish.yml[65]

+        platforms: linux/amd64,linux/arm64

Evidence

Multi-arch builds must successfully run all Dockerfile RUN steps for each target architecture.
This repo’s Dockerfile runs dependency installation and Prisma generation during build, which can be
architecture-sensitive and is a common cause of arm64 build failures/slowdowns without careful setup
and validation.

.github/workflows/docker-publish.yml[56-65]
Dockerfile[5-10]
Dockerfile[36-41]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
Multi-arch publishing can fail or be flaky when the Dockerfile runs build steps that may be architecture-sensitive (Node deps, Prisma engines).

### Issue Context
This workflow publishes `linux/amd64,linux/arm64` images, and the Dockerfile runs `npm install`, `npx prisma generate`, and `npm run build` during the image build.

### Fix Focus Areas
- .github/workflows/docker-publish.yml[31-65]
- Dockerfile[5-10]
- Dockerfile[36-41]

### Suggested change
- Add an explicit `docker/setup-qemu-action` step before build (even if Buildx may handle it) and/or add a CI check that builds arm64 and fails fast.
- If arm64 is not required immediately, consider publishing amd64 only until arm64 is confirmed stable.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

ⓘ The new review experience is currently in Beta. Learn more

[qodo-code-review]

2. Version tag retargeted 🐞 Bug ⛯ Reliability

The workflow tags every master build with the package.json version, so if the version isn’t bumped
on each commit, the same version tag will be overwritten to point at different images over time.
This breaks reproducibility and makes rollbacks/debugging unreliable (pulling 2.1.3 on different
days yields different binaries).

Agent Prompt

### Issue description
The workflow publishes a Docker tag equal to `package.json`'s version on every push to `master`, which can overwrite the same version tag to point at different images.

### Issue Context
`package.json` typically changes less frequently than commits to `master`, so `2.1.3` (example) would be re-pushed and no longer uniquely identify a build.

### Fix Focus Areas
- .github/workflows/docker-publish.yml[41-54]

### Suggested change
- Gate the raw `package.json` version tag so it is only emitted for tag builds (or remove it entirely and rely on `type=ref,event=tag`). For example, change the version tag line to use an enable condition for tag events (per `docker/metadata-action` syntax), or switch to `type=semver` driven by git tags.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools