ember-memory-test/episodes/EXPLORA_mixed-language-deploy-troubleshooting_S20260413.R13_FJ.ops.2.hot_exp.pr.cc.mx.DR0.MGQ_J.CFDFX_E.EGNFD.md

episode_id	puente_flat	session_code	acto_dialogico	actor_flujo	criticidad_aegis	skill_dominante	fase_proyecto	tipo_semantico	summary_one_line	source_type	trust_boundary	created_at	relectura_tagged	forgejo_commit_sha
8e026b73-804d-4e31-9acd-dcbfa0f10d4e	EXPLORA_mixed-language-deploy-troubleshooting_S20260413.R13_FJ.ops.2.hot_exp.pr.cc.mx.DR0.MGQ_J.CFDFX_E.EGNFD	S20260413	explicar	multi_actor	low	NONE	operations	troubleshooting	EPISODIO S13 — DOCKER: deliberate language mixing for gen_language heuristic stress	chat_ember	private	2026-04-13T12:55:31.824498+00:00	false	pending

El deployment del Docker container requiere configurar los environment variables en el .env file antes de ejecutar docker compose up. Los logs muestran connection refused cuando el upstream backend no esta healthy. This is a common issue when the container starts before the database is ready to accept connections.

Para resolver este problema, the health check configuration in the compose file should use depends_on with condition service_healthy. El Caddyfile necesita un upstream block that points to the correct container name, not the IP address. When Docker recreates a container, the IP changes but the DNS name stays the same dentro de la red ember-net.

The recommended approach tiene tres pasos. Primero, verificar que el .env file contiene todas las variables with their correct values. The most common missing variable es EMBER_AUTH_TOKEN which is required for the MCP server authentication. Segundo, revisar los health checks: each container should have a healthcheck directive en el docker-compose.yml that validates the service is actually responding, not just que el proceso esta corriendo.

Tercero, and this is the most critical step, the deployment order matters. PostgreSQL debe iniciar primero, followed by Qdrant and Neo4j, then the application containers como ember-mcp y n8n. This ordering is enforced by depends_on pero solo funciona when health checks are properly configured. Sin health checks, depends_on only waits for the container to start, which is not the same as waiting for the service to be ready para aceptar conexiones. El error mas comun es asumir que container started equivale a service ready.