docs: fix network topology — nginx is the only public door, gateway is private#16
Merged
Merged
Conversation
…s private The architecture diagrams described "Client → Gateway (public) → API (private)", omitting nginx and wrongly painting the gateway as the public entrypoint. docs/SECURITY.md even had the (public)/(private) labels reversed. The real topology (source of truth: production compose) is: Browser → Nginx (front) → Gateway → API → PostgreSQL, where only the `front` container is exposed and gateway/api/postgres all live on `internal-network` (`internal: true`) with no inbound from the Internet. - Rewrite the three architecture diagrams in Mermaid (renders natively on GitHub) in README.md, docs/README_eng.md and docs/SECURITY.md, fixing the reversed public/private labels and inserting nginx as the only public door. - Align prose in README.md, docs/README_eng.md and apps/gateway/AGENTS.md: the gateway is private (internal-network), behind nginx — not "the only service exposed to the Internet". - compose.yaml: move gateway to internal-network only (drop edge-network and its published port); put front on edge-network + internal-network so it can reach the gateway. Verified with `docker compose config`. Co-Authored-By: Claude Opus 4.8 <[email protected]>
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.
Qué
La arquitectura dibujada en los README describía
Cliente → Gateway (público) → API (privada), omitiendo nginx y pintando al gateway como la puerta pública. Ademásdocs/SECURITY.mdtenía las etiquetas(público)/(privada)invertidas.La topología real (fuente de verdad: el
compose.prod.yamlde producción) es:front) es el único servicio expuesto: sirve la SPA y hace reverse-proxy de/api/*al gateway (mismo origen → cookies sin CORS; el front usa ruta relativaapi: '/api/v1/'ynginx/default.confhaceproxy_pass http://gateway:3100).internal-network(internal: true), sin entrada desde Internet.Cambios
Diagramas reescritos en Mermaid (render nativo en GitHub) en
README.md,docs/README_eng.mdydocs/SECURITY.md, con nginx como única puerta pública y las etiquetas público/privado corregidas.Texto alineado en
README.md,docs/README_eng.mdyapps/gateway/AGENTS.md: el gateway pasa a describirse como privado tras nginx (se elimina "único servicio expuesto a Internet").compose.yamlalineado a producción: gateway movido ainternal-networkonly (se quitaedge-networky su puerto publicado);frontahora enedge-network+internal-networkpara poder alcanzar al gateway. Verificado condocker compose config:Notas
edge-networkse mantiene únicamente parafront, como equivalente local de la red proxy externa de Coolify (para que el publish de puerto al host siga funcionando).🤖 Generated with Claude Code