Community fixes: bot-runtime secret, configurable gateway upstreams, dynamic AI models#18
Community fixes: bot-runtime secret, configurable gateway upstreams, dynamic AI models#18DavidsonGomes merged 6 commits intomainfrom
Conversation
Align evo-bot-runtime with evo-crm and evo-crm-sidekiq, which already fall back to the shared dev secret when BOT_RUNTIME_SECRET is absent from .env. Previously the bot-runtime depended solely on env_file, so a .env copied from an older template left it with an empty secret — every event from the CRM then failed the X-Bot-Runtime-Secret check with pipeline.auth.unauthorized and the AI silently never replied.
The gateway nginx config had the five backend service names (evo_auth,
evo_crm, evo_core, evo_processor, evo_bot_runtime) baked into the image,
which broke any deployment that uses a different naming convention —
requests would hit DNS-NOT-FOUND upstreams and surface as 502s.
Replace the hardcoded host:port pairs with ${AUTH_UPSTREAM},
${CRM_UPSTREAM}, ${CORE_UPSTREAM}, ${PROCESSOR_UPSTREAM} and
${BOT_RUNTIME_UPSTREAM}, rendered at container start by the stock
nginx-image envsubst entrypoint. Defaults in the Dockerfile match the
previous hardcoded values exactly, so deployments that follow the
reference stack keep working with zero changes.
NGINX_ENVSUBST_FILTER is scoped to the five *_UPSTREAM names so the
rendering pass does not touch nginx's own runtime variables like $host
or $request_uri.
Adds develop to the trigger branches and emits evoapicloud/evo-crm-gateway:develop plus :develop-<sha> so pre-release gateway builds can be pulled and tested before cutting a tag. The main and tag paths are unchanged and :latest stays reserved for main/tag builds.
Adds nginx/README.md with the full upstream table, default values, the renaming scenario that motivated the feature, and verification steps. Also leaves a commented-out override block inline in the swarm stack (plus a note in the gateway service) so operators who rename the backend services see the escape hatch without having to dig into the nginx image.
The monorepo wraps git submodules whose own repos already run their own dependency updates. Running dependabot at this layer only produced PRs against committed submodule pointers, never the submodules themselves, which is not useful.
Bumps evo-ai-core-service-community and evo-ai-frontend-community to their feat/dynamic-ai-models tips. Together the two bumps wire the agent model picker to GET /api/v1/agents/apikeys/:id/models, which queries the provider's own models endpoint (OpenAI, Anthropic, Gemini, OpenRouter, DeepSeek, Together AI, Fireworks AI) with the stored API key. The frontend falls back to its hardcoded catalog for providers without a public listing endpoint or if the call fails, so nothing regresses for existing stacks. This ends the churn where the hardcoded model list had to be edited every time a provider shipped a new family (the immediate trigger was GPT-5 not appearing).
Reviewer's GuideMakes the gateway’s upstream backends configurable via environment variables, adds CI publishing for develop builds, fixes the bot-runtime secret default, upgrades AI-related submodules for dynamic model loading, documents the gateway configuration, and removes an unused Dependabot config. Sequence diagram for dynamic AI model loading in the agent wizardsequenceDiagram
actor User as AgentWizardUser
participant FE as Frontend_agent_wizard
participant CORE as Core_AI_service
participant API as Provider_API
User->>FE: Open_agent_wizard
FE->>CORE: GET /models?provider=current_provider
CORE->>API: Provider_specific_models_request
API-->>CORE: Models_list
CORE-->>FE: Models_list
FE-->>User: Render_live_model_catalog
alt Unsupported_provider
FE->>CORE: GET /models?provider=unsupported_provider
CORE-->>FE: Fallback_hardcoded_model_list
FE-->>User: Render_fallback_model_catalog
end
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
There was a problem hiding this comment.
Hey - I've found 2 issues
Prompt for AI Agents
Please address the comments from this code review:
## Individual Comments
### Comment 1
<location path="docker-compose.yml" line_range="248" />
<code_context>
LISTEN_ADDR: 0.0.0.0:8080
REDIS_URL: redis://:${REDIS_PASSWORD:-evoai_redis_pass}@redis:6379
AI_PROCESSOR_URL: http://evo-processor:8000
+ BOT_RUNTIME_SECRET: ${BOT_RUNTIME_SECRET:-evo-bot-runtime-dev-secret}
depends_on:
redis:
</code_context>
<issue_to_address>
**🚨 issue (security):** The default BOT_RUNTIME_SECRET value is predictable and might be unsafe if reused beyond local dev.
A hard-coded default secret is fine for local dev, but if this compose file is ever used in shared or production-like environments the value becomes trivial to guess. Consider requiring it to be explicitly set (`${BOT_RUNTIME_SECRET:?must_be_set}`) or clearly marking this default as local-only and unsafe to use elsewhere.
</issue_to_address>
### Comment 2
<location path="nginx/README.md" line_range="41-42" />
<code_context>
+
+### When you need to override
+
+If your deployment renames any of the backend services (e.g. applying a
+`evocrm_` prefix, or shortening to `auth`/`crm`/…) the gateway cannot
+resolve the default hostnames and every proxied request returns **502 Bad
+Gateway**. Set the matching `*_UPSTREAM` env vars on the gateway service
</code_context>
<issue_to_address>
**suggestion (typo):** Use "an" instead of "a" before `evocrm_` for correct article usage.
Because `evocrm_` begins with a vowel sound, this should be "applying an `evocrm_` prefix" for correct grammar.
```suggestion
If your deployment renames any of the backend services (e.g. applying an
`evocrm_` prefix, or shortening to `auth`/`crm`/…) the gateway cannot
```
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
| LISTEN_ADDR: 0.0.0.0:8080 | ||
| REDIS_URL: redis://:${REDIS_PASSWORD:-evoai_redis_pass}@redis:6379 | ||
| AI_PROCESSOR_URL: http://evo-processor:8000 | ||
| BOT_RUNTIME_SECRET: ${BOT_RUNTIME_SECRET:-evo-bot-runtime-dev-secret} |
There was a problem hiding this comment.
🚨 issue (security): The default BOT_RUNTIME_SECRET value is predictable and might be unsafe if reused beyond local dev.
A hard-coded default secret is fine for local dev, but if this compose file is ever used in shared or production-like environments the value becomes trivial to guess. Consider requiring it to be explicitly set (${BOT_RUNTIME_SECRET:?must_be_set}) or clearly marking this default as local-only and unsafe to use elsewhere.
| If your deployment renames any of the backend services (e.g. applying a | ||
| `evocrm_` prefix, or shortening to `auth`/`crm`/…) the gateway cannot |
There was a problem hiding this comment.
suggestion (typo): Use "an" instead of "a" before evocrm_ for correct article usage.
Because evocrm_ begins with a vowel sound, this should be "applying an evocrm_ prefix" for correct grammar.
| If your deployment renames any of the backend services (e.g. applying a | |
| `evocrm_` prefix, or shortening to `auth`/`crm`/…) the gateway cannot | |
| If your deployment renames any of the backend services (e.g. applying an | |
| `evocrm_` prefix, or shortening to `auth`/`crm`/…) the gateway cannot |
Summary
Accumulates the fixes committed on `develop` since the last merge to `main`:
Linked submodule PRs
Test plan
Summary by Sourcery
Update the API gateway configuration to support configurable upstream service targets, adjust related deployment and CI settings, and align runtime defaults and submodules with recent community fixes.
New Features:
Bug Fixes:
Enhancements:
Build:
CI:
Documentation:
Chores: