Kong – the overarching service orchestrator
The Supabase services are Docker containers, and those containers live in their own Docker network.So, whenever I say “Supabase service,” I’m referring to a Docker container. The fact that all Supabase services live within the same Docker network means that if one service, such as Storage, has a server running with an API for managing files in its container at localhost:3000, all the other services can access the API of that service with serviceName:3000 (so storage:3000). That also means that all the services can talk to each other via their REST APIs.
Usually, in production environments (such as supabase.com itself), none of the services are directly accessible to the outside, so from the outside, I cannot just use an API at storage:3000. Only containers that explicitly expose themselves to the public will be accessible to the outside, but none of the services in Supabase are—and this is best practice...
