Workflow automation tool failing to expose port in CI pipeline

Other Questions N8n
1

I’m having trouble with a workflow automation tool in our CI pipeline. It works fine on our local machines but fails when we run it on the CI server. The error says it can’t connect to the service:

ConnectionError: HTTPConnectionPool(host='localhost', port=1234): Max retries exceeded with url: /api/v1/credentials (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7f3d28e3d810>': Failed to establish a new connection: [Errno 111] Connection refused'))

Below is our docker-compose configuration:

  automation_service:
    image: example.com/automation-tool
    ports:
      - '1234:1234'
    environment:
      - SERVICE_HOST=automation_service:1234
      - SERVICE_PORT=1234
      - SERVICE_PROTOCOL=http
      - NODE_ENV=production
      - DB_TYPE=postgres
      - DB_PREFIX=auto_
      - DB_NAME=automation
    volumes:
      - ./config:/home/user/.config
      - ./data:/data

We’re accessing it through Python’s requests library within our FastAPI app. Can anyone suggest why it works locally but fails in our CI? Our docker-compose file is identical, and our testing script resets environment variables.

I reduced the issue to this:

curl --fail http://localhost:9090 || exit 1
curl --fail http://localhost:1234/api/v1/docs/ || exit 1

The first command passes, but the second returns ‘Connection refused’. I’ve also tried switching ports. Any ideas?

2

I encountered a similar issue in our CI pipeline. The problem might be related to how Docker networking works in CI environments. Try replacing ‘localhost’ with the service name in your connection string. So instead of ‘localhost:1234’, use ‘automation_service:1234’. This ensures the request is routed correctly within the Docker network.

Also, verify that your CI environment supports Docker in Docker (DinD) if you’re running containers inside a container. Some CI platforms require specific configuration for this to work properly.

Lastly, check your CI logs for any container startup errors. Sometimes services fail silently, and the root cause isn’t immediately apparent from the connection error alone.

3

hey there, have u tried checking if the service is actually running on the CI server? sometimes containers fail to start properly. maybe try adding a health check to ur docker-compose file to ensure the service is up before running tests. also, double-check that the port isn’t being used by another process on the CI machine.

4

I’ve run into this exact problem before, and it’s usually due to networking differences between local and CI environments. One thing that worked for me was explicitly setting the host to ‘0.0.0.0’ in the service configuration. This binds the service to all available network interfaces, which can help in CI setups.

Try modifying your docker-compose like this:

automation_service:
  ...
  command: ['your-command', '--host', '0.0.0.0']
  ...

Also, make sure your CI isn’t using network isolation that might prevent services from communicating. Some CI platforms have settings for this.

If that doesn’t work, you might need to dig into your CI’s network setup. Sometimes, they use custom DNS or routing that can interfere with service discovery. In that case, you might need to configure your CI to use the Docker network directly.

Lastly, have you tried running ‘docker-compose ps’ in your CI to verify all services are actually up and running as expected? Sometimes a silent failure in startup can cause these kinds of connection issues.