I’m having trouble with a containerized workflow automation tool in my CI pipeline. The setup works perfectly on my local machine but breaks when running in GitHub Actions.
The Problem
My Docker Compose configuration includes a workflow service that should expose its API on port 5678. When I test locally everything connects fine, but in the CI environment I get connection refused errors.
ConnectionError: HTTPConnectionPool(host='localhost', port=5678): Max retries exceeded with url: /api/v1/credentials
Testing Commands
curl --fail http://localhost:8080 || exit 1 # This works
curl --fail http://localhost:5678/api/v1/docs/ || exit 1 # This fails
I have another service on port 8080 that works fine in the same compose file. Only the workflow service fails to accept connections. Has anyone encountered similar port exposure issues in GitHub Actions? What could cause this difference between local and CI environments?
i think ur right about the timing. try adding a healthcheck to ur compose file so it waits for the service to be ready b4 trying to hit the endpoint. actions can be slower than local setups, so it makes sense!
This is a network connectivity issue with GitHub runners. Your local setup works differently than GitHub Actions - the runner uses a different Docker network setup. You’ve got N8N_HOST set to workflow-service:5678 but your test tries to connect to localhost:5678. GitHub Actions services don’t automatically bind to localhost like they do locally. Try changing your test command to use the service name instead of localhost, or map the service to the runner’s localhost by adding service configuration in your workflow file. I ran into the same thing with database connections in CI - explicitly defining the service in the GitHub Actions YAML with proper port mapping fixed it.
Check your GitHub Actions workflow config - you’re missing a services section. GitHub Actions doesn’t auto-expose ports like local setups do. You need to specify the service in your workflow YAML with proper port mapping:
If you’re using Docker Compose in your action, the problem might be that the compose network isn’t reachable from the runner. Services can talk to each other but stay isolated from the host. Try using docker-compose exec to test connectivity from inside the network first - this’ll help you figure out if it’s a service startup issue or routing problem.