OB1 Feels Surprisingly Clean, Until Docker Networking Enters the Conversation

Upon reviewing the OB1 project, the initial impression was quite favorable. The architecture was straightforward, featuring a single database, AI gateway, and chat interface. The self-hosted nature of the system appealed to a gateway engineer, as it allowed for greater control over prompts, responses, and routing within a private network. This setup would certainly provide a strong foundation for team governance, keeping sensitive information securely contained.

However, the use of Docker for deployment introduced some unforeseen complications. When attempting to connect the chat-facing container to the AI gateway, the container could not reach the intended service. The configuration appeared correct at first glance, as the environment variable AI_GATEWAY_URL was set to http://localhost:8080.

This URL worked seamlessly from the host machine, but inside the Docker container, localhost refers to the container itself, not the host system. Consequently, the connection attempt resulted in a frustrating connection-refused error, masking the underlying network configuration issue.

The resolution was simple: instead of using localhost to reference the AI gateway, the service name should be employed. By configuring the OB1 services with the appropriate networking settings, both the chat container and AI gateway could operate on the same internal Docker network, eliminating the connection issues. The services were defined as follows:

services:

ob1:

environment:

AI_GATEWAY_URL: http://ai-gateway:8080

depends_on:

- ai-gateway

ai-gateway:

expose:

- 8080

After making these adjustments, the stack was rebuilt using the commands:

docker compose down

docker compose up -d --build

docker compose logs -f ob1

It is also crucial to review the .env file before exposing the system publicly. Strengthening database credentials, avoiding the binding of internal ports to 0.0.0.0, and securing the chat endpoint behind a private reverse proxy or VPN are essential steps to maintain privacy. Self-hosting alone does not guarantee privacy if the Docker network and logs are left open to unauthorized access.

In conclusion, OB1 presents a compelling architecture with a clean foundation and the appealing "one brain, one gateway" model. However, teams adopting this system must be mindful of Docker networking, secret handling, and retention policies. Assigning ownership for tasks such as backups, token quotas, and zero-log expectations is vital to ensure the system's security and proper operation.