Both pages start ~/insforge on the default ports, then hand project1 those same
ports in the multi-instance section. Anyone reading either page end-to-end brings
up the second one into a bind failure.
Same note in both, since the README carries a copy of this section.
`cp .env.example .env.project1` gave every instance the placeholder secrets the
file ships — the same published JWT_SECRET on each, plus POSTGRES_PASSWORD=postgres
and ROOT_ADMIN_PASSWORD=change-this-password. The note below it asked readers to
change JWT_SECRET and ROOT_ADMIN_PASSWORD, which is two of the six and reads as
hardening rather than as "these are public".
Running setup.sh into a directory each generates a real set per instance, and
matches what the README already says. Verified: two directories get different
secrets, neither placeholder, and compose resolves them as separate projects.
The --env-file form goes with it — one .env per directory means plain
`docker compose` from inside it, which is what COMPOSE_FILE is set up for.
The steady trickle of small findings has one cause: I have been fixing this
corpus with grep-driven sweeps, and every pattern has been narrower than the
corpus. 30 of these files are near-duplicate translated prose, so each logical
fix landed in twelve files and missed four — the variants being case
(`~/InsForge` vs `~/insforge`), indentation (fences nested in list items),
translated phrasings that do not match the English anchor, and code comments
rather than prose. Reviewers then found the remainder, one batch at a time.
So this pass wrote the invariants down and checked all 34 changed deploy files
against them mechanically. Thirteen rules, ten violations, all fixed:
- Azure's update commands used `~/InsForge` while its setup step creates
`~/insforge` — case-sensitive on Linux, so the documented update fails before
it starts. Four locales.
- The image-only compose probed `pg_isready -U postgres` with POSTGRES_USER
configurable one line above, so overriding the user left Postgres permanently
unhealthy and, since insforge gates on it, never started the backend. The same
class of bug as the postgrest healthcheck, in the same file. Verified: with
POSTGRES_USER=ifadmin the container now reaches healthy.
- The update procedure's review diff covered `deploy` and `.env.example` but not
`functions/`, which is in the sparse checkout and which the Deno service
executes. Four locales.
- Section 5.2 still told the reader to set POSTGRES_PASSWORD, two sections after
4.2 started the stack — and Postgres only reads it at cluster init, so the
instruction could not work. It says so now. Four locales.
- setup.sh only added COMPOSE_FILE when absent, so a .env copied from the
template by hand kept pointing at the development stack, whose files the
checkout does not contain. It now repoints that exact value, and leaves
anything else — including a hand-appended storage overlay — alone.
- MD040 on two fences, and the update prose that called an update "a pull and
restart" when the checkout carries Postgres's config and the Deno functions.
The audit also caught something no reviewer did: .env.example's COMPOSE_FILE has
to stay equal to what Compose discovers on its own in that directory, which
changed when docker-compose.override.yml was deleted earlier in this branch.
It is equal — verified byte-for-byte against auto-discovery — and setup.sh's
self-heal constant now has to match it, with both sides commented.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
From cubic's pass, after reproducing each:
- setup.sh's migration branch exits before the fresh-install path's `chmod 600`,
so an install whose old .env was group-readable stayed that way. It now
chmods right after the move; verified by handing it a 644 file.
- The multi-instance section had `cp .env.example .env.projectN` with no further
instruction, and .env.example now ships COMPOSE_FILE's development value —
a file the sparse checkout does not contain. Each copy needs the production
path.
- ROOT_ADMIN_PASSWORD is mandatory in the platform files now, alongside
JWT_SECRET and ENCRYPTION_KEY. Unlike POSTGRES_PASSWORD there is no migration
hazard: auth.service.ts hashes it from the environment on every boot rather
than persisting a record, so changing it takes effect on restart. A dashboard
reachable from the internet on `changeme123` is the most directly exploitable
of the three placeholders.
- The zh, zh-Hant and es guides' section 5.5 still listed AWS_S3_BUCKET/AWS_*,
which the compose file does not pass, while English had moved to S3_*. The
note I added to 5.4 pointed at "the S3_* variables in 5.5" — which did not
exist in those three. Aligned on the names the compose actually reads.
- GCE's backup snippet still said "run from deploy/docker-compose/" in a code
comment, which the earlier path sweep did not match.
- Containarium's agent flow wrote the whole of ~/insforge/.env, overwriting the
secrets setup.sh had just generated two steps earlier.
Also updates the backend skill note, which claimed the two platform files differ
only in INSFORGE_DEPLOYMENT_METHOD; the build context differs too, since Coolify
builds with --project-directory and Dokploy does not.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
- The quickstart is the setup.sh one-liner, with a download-and-read variant
for anyone who will not pipe a script to a shell. The old "do the same by
hand" block reproduced the script's sparse-checkout list, which had already
drifted once when the list gained deploy/setup.sh and the copy did not.
- Every command runs from the checkout root. The four cloud guides (AWS EC2,
Azure VM, GCE, Containarium) cloned the full monorepo — 1,782 files, 57.6MB —
and then ran the image-only compose file anyway; none reference a build step.
They use setup.sh now, which also stops walking the reader through inventing
JWT_SECRET by hand or pasting a placeholder over a generated secret.
- New Coolify and Dokploy guides. Both platforms had compose files in the repo
and no documentation; Coolify appeared once, in a list of telemetry values.
- COMPOSE_PROJECT_NAME is documented with its consequence: any .env on the host
carrying the same name means `docker compose up` there adopts and recreates
that project's containers.
- self-host-storage.mdx covers the image-only stack, which it never did —
appending an overlay to COMPOSE_FILE rather than passing -f flags.
- Section 5.4 no longer tells self-hosters to set AWS_ACCESS_KEY_ID and
AWS_SECRET_ACCESS_KEY; the compose file passes neither.
- The automated backup script pointed -f at a compose file the checkout does
not contain, and -f alone loads neither COMPOSE_FILE nor
COMPOSE_PROJECT_NAME from .env, so its `exec` would not have found the
container.
Registered in docs/deployment/README.md and docs.json's English tree, locale
trees regenerated with scripts/build-docs-langs.py. The i18n parity check
reports the same 24 pre-existing gaps as before.
Not verified: the domain-assignment step in the two platform guides. Coolify's
auto-assigned application FQDN returns 404 because a compose deployment binds
domains per service, and I found no API field for that; the Dokploy stack was
checked over the container network. Both steps follow the platforms' own docs.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
- Rename title from "How to use Dockerized InsForge (for development)" to "Deploy InsForge with Docker"
- Remove redundant "Configure the .env file" step
- Renumber steps (Step 1, 2, 3)
- Fix image formatting to use consistent centered div with width="600"
- Convert Sample Project Prompt to code block format
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Lyu