CapRover template pins 0.9.66 and describes AI features 0.15.0 does not ship

[yusuf-gundogdu]

Summary

deploy/caprover/libredb-studio.yml pins 0.9.66 and now describes AI features that 0.15.0 does not ship. The catalog copy at caprover/one-click-apps sits further back at 0.9.59, so anyone installing from the CapRover catalog today gets a build from July.

Checked against the 0.15.0 image and origin/main, not against the docs.

Where the three versions stand

File	Pinned	Behind current
deploy/caprover/libredb-studio.yml	0.9.66	15 releases
public/v4/apps/libredb-studio.yml (catalog)	0.9.59	22 releases
Current release	0.15.0

This has a known cause. #224 raised the same gap in July, when the catalog was pinned at 0.9.14. The fix went straight to the catalog as #1315 and left this file behind, and the two have been out of step since. The README here already predicts it under "Nothing verifies this file", and #268, the issue that tracked that gap, is closed.

Four changes

1. The pinned version, two places. Line 30 defaultValue: '0.9.66' and the example on line 31.

2. The AI description promises three features that were removed. Line 56 reads:

OPTIONAL - turns on AI query help (natural-language to SQL, explain, fix).

Natural-language to SQL, autopilot, chat, impact and index-advisor are all gone. The AI routes inside each image:

0.9.59   autopilot  chat  describe-schema  explain  impact  index-advisor  nl2sql  query-safety
0.15.0   describe-schema  explain  query-safety

docs/AGENT.md is explicit that the agent rail did not absorb the old behaviour: an investigation "cannot propose anything". So the sentence needs rewriting, not trimming. The LLM_* fields themselves stay, the agent resolves its model through the same config.

3. The API URL description is wrong. Line 68 says the variable is "for ollama/custom providers only (not for gemini/openai)". resolveApiUrl in src/lib/llm/utils/config.ts returns LLM_API_URL before it ever looks at the provider, and src/lib/agent/provider-registry.ts notes that Gemini reads it too. Only custom requires it; every provider honours it.

4. Rotating JWT_SECRET now empties saved connection passwords. src/lib/storage/encryption.ts derives the credential key from JWT_SECRET when STORAGE_ENCRYPTION_KEY is unset, and says so in its own header: "rotating JWT_SECRET invalidates every stored credential". The template generates JWT_SECRET and never mentions STORAGE_ENCRYPTION_KEY.

I ran both images against the same volume to see what actually happens.

On 0.9.59, saved a connection with the password PAROLA_DENEME_12345, then searched the SQLite files:

/app/data/s.db-wal   matches for PAROLA_DENEME_12345: 1
GET /api/storage?collection=connections
  "password": "PAROLA_DENEME_12345"

Plain text on disk, plain text on read. Rotating JWT_SECRET there changes nothing.

On 0.15.0, same connection, same volume:

/app/data/s.db       matches for PAROLA_DENEME_12345: 0
/app/data/s.db-wal   matches for PAROLA_DENEME_12345: 0
envelopes found:     v1:pJgyI7ruRhKhB4SB...  v1:N1zSBYcqtXmzjlyc...

Encrypted, as intended. Then I restarted that same volume with a different JWT_SECRET. Login still works, the connection row is still there, and the password is gone:

{"connections":[{"id":"t1","name":"deneme","type":"postgresql","host":"h","port":5432,"database":"d","username":"u"}]}

The API returns 200 and no error. The only sign is in the log:

[WARN] {provider=storage-encryption} Stored connection secrets could not be decrypted:
1 field(s) were omitted. Restore the previous JWT_SECRET (or STORAGE_ENCRYPTION_KEY)
BEFORE the app writes again, or re-enter the affected credentials.

So the product already says the right thing, in the right words, in a place the CapRover user will never look.

CapRover fills $$cap_gen_random_hex once in the browser and keeps the value, so a normal version bump does not trigger this. It matters for anyone who edits that variable by hand, and the warning's own advice, restore the old value before the app writes again, is time-sensitive. One line in instructions.end covers it. Setting STORAGE_ENCRYPTION_KEY keeps the credential key separate from the auth secret.

What I checked on 0.15.0

Ran the image with exactly the variables the template sets:

• Both accounts log in and return the right roles, admin and user.
• Every variable in the template is still read, and the app starts cleanly with the AI variables filled or blank.
• Port 3000, the /app/data volume and the provider list gemini | openai | ollama | custom all still match.
• /api/db/health answers 200 without a session, so the CapRover health check has something to hit.

The upgrade itself is safe. Nothing between 0.9.66 and 0.15.0 breaks stored data, and the old plain-text values are re-wrapped on the next write.

After this

Once this file is updated I will send the same content to caprover/one-click-apps so the catalog matches. The duplicate check there is clean: #1303 and #1315 merged, nothing open.