Update to use a base64 encoded key

.env.example

@@ -37,34 +37,45 @@ NODE_ENV=development
 # ──────────────────────────────────────────────────────────────────
 # Build-time — values the `docker compose build` step uses
 # ──────────────────────────────────────────────────────────────────
-# These are only needed when BUILDING the image, not when running
-# it. The image talks to git.kadil.dev to fetch the `goods-editor`
-# git+ssh: npm dependency during `npm install`. See the docblock
-# in Dockerfile for the full mechanism.
+# Only needed when BUILDING the image, not when running it. The
+# image talks to git.kadil.dev to fetch the `goods-editor` git+ssh:
+# npm dependency during `npm install`. See the Dockerfile docblock
+# for the full mechanism.
 #
-# ── Option A: file-based key (typical local dev / single deploy host)
-# Set this to the absolute path of a private SSH key that has read
-# access to the goods-editor-module repo. The key file stays on
-# disk; only its contents are mounted into the build for the one
-# RUN step that needs it, and nothing about it ends up in the
-# image layers.
+# The Dockerfile expects a BASE64-ENCODED private key (not raw PEM)
+# because that's the format Dokploy's Build-time Secrets textarea
+# requires — it's dotenv-parsed and can't handle multi-line values.
+# We use base64 for local builds too so the Dockerfile has one input
+# format. Encode like this:
 #
-# Recommended: generate a dedicated read-only deploy key rather
-# than reusing a personal key (see Dockerfile docblock for the
-# ssh-keygen + Gitea deploy-key registration steps).
+#   base64 < ~/.ssh/goods-editor-deploy | tr -d '\n' > /tmp/key.b64
 #
-# Examples (uncomment one):
-# SSH_KEY_FILE=/Users/khalid/.ssh/goods-editor-deploy
-# SSH_KEY_FILE=/home/deploy/.ssh/goods-editor-deploy
+# Recommended: generate a dedicated read-only deploy key rather than
+# reusing a personal key (see Dockerfile docblock for the ssh-keygen
+# + Gitea deploy-key registration steps).
+#
+# Path to a base64-encoded key file. Uncomment one for local builds:
+# SSH_KEY_FILE=/Users/khalid/.ssh/goods-editor-deploy.b64
+# SSH_KEY_FILE=/home/deploy/.ssh/goods-editor-deploy.b64
 
-# ── Option B: env-var-based key (typical CI)
-# Pass the key contents directly via SSH_PRIVATE_KEY. Don't put
-# the actual key in this .env file (multi-line values are fragile
-# in env files, and committing a key — even .env.example with
-# real material — is a leak waiting to happen). Set it from the
-# shell or from your CI's secret store:
+# Alternative: env-var-based (CI). To use this mode, also flip
+# docker-compose.yml's `secrets.ssh_key` block from `file:` to
+# `environment:` (see comments there). Set the base64 contents via
+# the shell or your CI secret store:
 #
-#   SSH_PRIVATE_KEY="$(cat ~/.ssh/goods-editor-deploy)" docker compose build
+#   SSH_KEY_B64="$(base64 < ~/.ssh/goods-editor-deploy | tr -d '\n')" \
+#     docker compose build
 #
-# To use this mode, also flip docker-compose.yml's `secrets.ssh_key`
-# block from `file:` to `environment:` (see comments there).
+# Don't put the actual base64 in this .env file. The string is long
+# enough that dotenv parsers may struggle, and committing real key
+# material — even base64 — to a repo is a leak waiting to happen.
+#
+# ── Dokploy ───────────────────────────────────────────────────────
+# The entries above DON'T apply to Dokploy. In Dokploy, paste the
+# base64 directly into the application's Environment → Build-time
+# Secrets textarea as a single line:
+#
+#   ssh_key=<that base64 string>
+#
+# Dokploy parses that textarea as dotenv and passes the value into
+# the build as a BuildKit secret named `ssh_key`.