v0.87.0 — Data apps get Storage access by default
Storage access for data apps is now on by default
kbagent data-app create gains --workspace / --no-workspace, defaulting ON. It writes runtime.workspace.enabled: true — the single switch that makes the platform provision the app's ephemeral workspace and inject WORKSPACE_ID, QUERY_SERVICE_URL and KBC_WORKSPACE_MANIFEST_PATH.
Why
kbagent never wrote that flag and offered no option to. An app that reads Storage — including every app built from the dataapp-developer skill's DuckDB-cached read-only pattern — deployed, reported state=running, and passed its health probe while unable to read a single row. The platform emits no diagnostic for this: an app that checks its own environment logs something like Missing env vars: WORKSPACE_ID, and one that doesn't crash-loops behind the probe instead. Silently serving zeros was the default outcome.
Upgrading
New apps need nothing. Apps created by kbagent 0.86.0 or earlier still have the dead data path — the authoritative check is the config, not the log:
kbagent --json config detail --project P --component-id keboola.data-apps \
--config-id <cfg> | jq '.data.configuration.runtime'
# no "workspace": {"enabled": true} -> this is your bugRetrofit (both steps — a config update alone never reaches the running container):
kbagent config update --project P --component-id keboola.data-apps \
--config-id <cfg> --merge --set 'runtime.workspace.enabled=true'
kbagent data-app deploy --project P --app-id <ID> --waitNotes
--no-workspaceomits the key rather than writingenabled: false, so that request body is byte-identical to 0.86.0. Use it for an app that never touches Storage.- The block is a sibling of
runtime.backend, matching what the UI and MCP'smodify_python_js_data_appwrite. - Not gated on any project feature — the config option is the sole control.
- Mirrored on the
serveREST surface as"workspace": trueinPOST /data-apps/{project}, and reported asworkspacein the--jsonenvelope. secrets-setnow warns when a secret's derived env-var name collides withWORKSPACE_ID,QUERY_SERVICE_URLorKBC_WORKSPACE_MANIFEST_PATH— those are platform-injected once Storage access is on, so such a secret is silently shadowed.
Full changelog: kbagent changelog --limit 1 --full