chore: bind CI server to 0.0.0.0:8100 for container bridge access#8
Merged
Conversation
The CI server previously bound to 127.0.0.1:8100, which is reachable from the host's loopback but not from container bridges. This prevented Docker worker containers and Incus DTU containers from dispatching events to the server, even when the AMPLIFIER_CONTEXT_INTELLIGENCE_SERVER_URL env var was correctly set. Bind to 0.0.0.0:8100 makes the server reachable from: - Host loopback (unchanged) - Host's LAN IP (now) - Docker container bridge (now) - Incus container bridge (now) Changes: - server-config.example.yaml: change server_host default from 127.0.0.1 to 0.0.0.0; expand comment to explain why 0.0.0.0 is required for container bridge access and when 127.0.0.1 is appropriate. - README.md: update inline YAML example in 'Running Without Docker' section to show server_host: 0.0.0.0 with inline comment; add 'Network Access and Security' section explaining 0.0.0.0 binding behaviour and guidance for operators deploying in non-isolated environments. Note: config.py already defaults to server_host=0.0.0.0 (correct). The example config and README were the only places advertising 127.0.0.1. This is Stage 0 of a multi-stage rollout that makes CI dispatch work across the Resolve stack (host-direct AND in-DTU scenarios). Security note: 0.0.0.0 binding exposes the server on all interfaces. Operators deploying beyond a single-user dev box should firewall port 8100. README.md updated with this guidance.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The CI server example configuration previously advertised
server_host: 127.0.0.1, which is reachable from the host's loopback but not from container bridges. This prevented Docker worker containers and Incus DTU containers from dispatching events to the server, even when theAMPLIFIER_CONTEXT_INTELLIGENCE_SERVER_URLenv var was correctly set.What changed
server-config.example.yaml: Changeserver_hostfrom127.0.0.1to0.0.0.0; expand comment to explain why 0.0.0.0 is required for container bridge access and document the security trade-off.README.md: Update inline YAML example in the 'Running Without Docker' section to showserver_host: 0.0.0.0with inline comment; add 'Network Access and Security' section explaining 0.0.0.0 binding behaviour and guidance for operators deploying in non-isolated environments.Note on code.py default
config.pyalready defaults toserver_host = "0.0.0.0". The example config and README were the only places advertising127.0.0.1.Bind to 0.0.0.0 makes the server reachable from:
Tests
1174 passed, 1 pre-existing failure (
test_first_run_credentials_yaml_has_expected_keys—bolt://vsneo4j://URL scheme mismatch, not related to this change; confirmed failing onmainbefore this PR).Stage 0 of multi-stage rollout
This is Stage 0 of making CI dispatch work across the entire Resolve stack (host-direct AND in-DTU scenarios). Stages 1–3 will wire up ambient context intelligence in the Resolve session factory, orchestrator, and bundle documentation.