fix: replace removed bitnami/kafka with apache/kafka, production-hard…

[tusharkhatriofficial]

…en deployment

• Switch Kafka image from bitnami/kafka:3.7 (removed from Docker Hub) to apache/kafka:latest (official KRaft image)
• Convert Bitnami KAFKA_CFG_* env vars to native KAFKA_* format
• Rewrite Dockerfile as 3-stage build: Node (dashboard) → Maven (JAR) → JRE runtime — serves both API and dashboard on :8080
• Add .dockerignore to exclude .git, node_modules, ai-docs from builds
• Use eclipse-temurin:21-jre instead of jdk (saves ~300MB)
• Run app as non-root user (eventara)
• Add resource limits to prod compose (postgres 1G, kafka 1G, redis 512M, eventara 1G)
• Add healthcheck start_period for slower VPS environments
• Remove SPRING_JPA_HIBERNATE_DDL_AUTO override that conflicted with Flyway in dev compose
• Rewrite DEPLOYMENT.md with Coolify, DigitalOcean, and VPS guides
• Add EVENTARA_PORT and JAVA_OPTS to .env.example

[charliecreates]

Key deployment hardening items are currently undermined by (1) apache/kafka:latest being unpinned and (2) Compose deploy.resources.limits often being ignored outside Swarm. The container’s JAVA_OPTS setting is also not applied by the Dockerfile entrypoint, so JVM tuning guidance won’t work. .dockerignore is overly aggressive (notably ignoring Dockerfile), which can break remote/CI builders that rely on the build context.

Additional notes (2)

• Compatibility | docker-compose.prod.yaml:18-18
deploy.resources.limits in docker-compose.prod.yaml is ignored by docker compose up outside of Swarm mode for many Docker setups. That means the documented “memory limits” may not actually apply on the target VPS, defeating the stated hardening.

If your intent is to enforce limits in standard Compose, you should use Compose-supported settings (e.g., mem_limit) or document clearly that limits require Swarm / a compatible implementation.

• Maintainability | Dockerfile:1-8
  The dashboard build stage only copies eventara-dashboard/package*.json before npm ci. If the dashboard uses package-lock.json (good) this is fine, but if it uses pnpm-lock.yaml/yarn.lock or npm workspaces, the caching/install may be incorrect. Also, npm ci --production=false is an odd flag; npm ci already installs devDependencies by default unless NODE_ENV=production or --omit=dev is used.

This isn’t necessarily broken, but it’s brittle and a bit confusing in a “production hardened” Dockerfile.

Summary of changes

Summary of changes

• Added a .dockerignore to reduce Docker build context (ignores node_modules, .git, docs, compose files, etc.).
• Updated .env.example to reflect Kafka KRaft CLUSTER_ID and documented EVENTARA_PORT + JAVA_OPTS.
• Rewrote DEPLOYMENT.md with updated guidance (Coolify + VPS steps), resource limits, and env var table.
• Replaced bitnami/kafka:3.7 with apache/kafka:latest in both compose files and migrated Bitnami KAFKA_CFG_* env vars to native KAFKA_*.
• Hardened docker-compose.prod.yaml with start_period on healthchecks, memory limits, configurable app port, and JAVA_OPTS.
• Reworked Dockerfile into a 3-stage build (dashboard → backend → JRE runtime) and runs the container as a non-root user.
• Minor README tweak to remove the pinned Kafka version string.

[charliecreates]

Using apache/kafka:latest is a reproducibility and stability risk. A new upstream release can change defaults, KRaft metadata behavior, or paths, and your deployment could break on the next docker compose up.

Given this PR’s goal is to “production-harden” deployment, the image should be pinned to a specific Kafka version (or at least a major/minor tag) and ideally to a digest.

Suggestion

Pin the Kafka image to a known-good version and (optionally) a digest, e.g.:

• image: apache/kafka:3.7.2 (or whatever you validated)
• or image: apache/kafka@sha256:<digest>

Do the same in docker-compose.yaml.

Reply with "@CharlieHelps yes please" if you'd like me to add a commit pinning the image tag in both compose files.

[charliecreates]

JAVA_OPTS is set in the container environment, but the Dockerfile ENTRYPOINT never consumes it (it always runs java -jar app.jar). Unless your base image provides a wrapper that reads JAVA_OPTS (Temurin images typically do not), this variable will be ignored and the memory tuning guidance in .env.example/docs won’t work.

This is a functional issue: users will think memory limits are applied when they aren’t.

Suggestion

Update the entrypoint to actually apply JAVA_OPTS. Common patterns:

• Shell form:
  • ENTRYPOINT ["sh", "-c", "exec java $JAVA_OPTS -jar app.jar"]

Or keep exec form by using CMD:

• ENTRYPOINT ["sh", "-c"]
• CMD ["exec java $JAVA_OPTS -jar app.jar"]

Reply with "@CharlieHelps yes please" if you'd like me to add a commit implementing this change safely (including quoting/exec).

[charliecreates]

The Dockerfile comment says Vite builds to ../src/main/resources/static relative to eventara-dashboard, but the actual copy step pulls from /app/src/main/resources/static (i.e., outside /app/eventara-dashboard). That only works if the Vite config truly outputs to /app/src/main/resources/static inside the container.

Given the build stage WORKDIR is /app/eventara-dashboard, a common output would be /app/eventara-dashboard/dist. If the Vite output path ever changes, the Docker build will silently produce an image without the dashboard.

This is fragile because it relies on a non-standard output directory and a hard-coded cross-directory path.

Suggestion

Make the dashboard artifact path explicit and robust:

• Prefer building to the default dist/ and then copying into backend resources:
  • COPY --from=dashboard-build /app/eventara-dashboard/dist ./src/main/resources/static/

If you intentionally build directly into ../src/main/resources/static, add a quick sanity check to fail fast:

• RUN test -f /app/src/main/resources/static/index.html

Reply with "@CharlieHelps yes please" if you'd like me to add a commit that switches to copying from dist/ (or adds the fail-fast check).

[charliecreates]

You renamed KAFKA_KRAFT_CLUSTER_ID → CLUSTER_ID in .env.example and compose. That’s fine for the new image, but it’s a breaking change for anyone with existing .env files from previous versions. The docs mention stability, but there’s no explicit migration note that users must rename the variable (or they’ll silently fall back to the default).

Given the importance of cluster IDs, silently defaulting could accidentally create a new cluster metadata state when users expected their old one.

Suggestion

Add a short migration note in DEPLOYMENT.md (or README) such as:

• "If upgrading from older versions, rename KAFKA_KRAFT_CLUSTER_ID to CLUSTER_ID in your .env."
• Optionally support both temporarily in compose: CLUSTER_ID: ${CLUSTER_ID:-${KAFKA_KRAFT_CLUSTER_ID:-NvDm...}}

Reply with "@CharlieHelps yes please" if you'd like me to add a commit implementing backward-compatible env var fallback plus the doc note.

[charliecreates]

The prod docs state the compose file "sets memory limits" totaling ~3.5GB. Given deploy.resources often won’t apply in standard Docker Compose (non-Swarm), this section is potentially misleading and could cause operators to size their VPS incorrectly.

This should be aligned with the actual behavior of the compose file.

Suggestion

Clarify how limits are enforced:

• Add a note like: "deploy.resources is applied in Swarm; for plain docker compose up limits may not be enforced".
• If you adopt mem_limit (see compose suggestion), update the docs to say limits are enforced by Docker.

Reply with "@CharlieHelps yes please" if you'd like me to add a commit updating DEPLOYMENT.md to accurately describe limit enforcement.