feat: add/update ZeroClaw template (v0.7.1-beta.1048)#805
feat: add/update ZeroClaw template (v0.7.1-beta.1048)#805theonlyhennygod wants to merge 1 commit intoDokploy:mainfrom
Conversation
dosubot
bot
added
size:S
built with Refined Cloudflare Pages Action⚡ Cloudflare Pages Deployment
|
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| @@ -0,0 +1,16 @@ | |||
| [variables] | |||
| main_domain = "${domain}" | |||
| api_key = "${password:64}" | |||
There was a problem hiding this comment.
The api_key variable is populated via the password helper (generates a random string), which is then injected as API_KEY. Since PROVIDER defaults to openrouter, this key is almost certainly the user's LLM provider credential — a randomly generated string is not a valid OpenRouter key and will cause all AI calls to fail after deployment.
If API_KEY is instead ZeroClaw's own gateway access key (securing inbound requests), please add a comment to clarify. If it is the LLM provider credential, users must supply it manually and the template should accept it as a user-provided input rather than auto-generating a value. Is API_KEY the user's LLM provider credential (e.g. OpenRouter key), or is it ZeroClaw's own internal gateway auth token? If it's the former, a randomly generated value will break all AI calls out of the box.
| restart: unless-stopped | ||
| environment: | ||
| - API_KEY=${API_KEY} | ||
| - PROVIDER=${PROVIDER:-openrouter} |
There was a problem hiding this comment.
PROVIDER=${PROVIDER:-openrouter} uses Compose's variable-substitution default syntax, but template.toml already unconditionally sets PROVIDER=openrouter in env. The shell-default syntax is harmless and valid in Compose v3.8, but the duplication is unnecessary and could confuse users who look only at the Compose file and expect to be able to override PROVIDER there.
| - PROVIDER=${PROVIDER:-openrouter} | |
| - PROVIDER=${PROVIDER} |
Or simply keep it as-is in template.toml and use PROVIDER=openrouter as a plain literal in the Compose file to match the other env vars.
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
1 participant
Summary
ghcr.io/zeroclaw-labs/zeroclaw:${VERSION}Checklist
Testing
Links
Greptile Summary
This PR adds a new ZeroClaw template (v0.7.1-beta.1048), an AI personal assistant service written in Rust. The Compose file correctly follows all repository conventions (version 3.8,
exposenotports, named volumes,restartpolicy). One question needs clarification before this can be considered fully functional: whetherAPI_KEYis ZeroClaw's own gateway authentication token or the user's LLM provider credential.API_KEYauto-generation (template.tomlline 3): Thepasswordhelper generates a random string that is mapped toAPI_KEY. If this is the user's OpenRouter (or other provider) API key, the service will deploy but all AI calls will fail because a randomly generated value is not a valid provider credential. Please clarify the intended semantics and, if it is an external credential, accept it as a user-provided input instead.Confidence Score: 4/5
Safe to merge structurally, but the API_KEY semantics should be clarified to avoid a non-functional default deployment.
All Compose conventions are followed correctly. The only blocking question is whether the auto-generated API_KEY will cause the service to fail when connecting to an LLM provider — if API_KEY is ZeroClaw's internal gateway auth this is fine; if it is the provider credential it is P1 and needs to be user-supplied.
blueprints/zeroclaw/template.toml — clarify whether API_KEY should be auto-generated or user-provided.
Reviews (1): Last reviewed commit: "feat: add/update ZeroClaw template (v0.7..." | Re-trigger Greptile