feat: add SUPABASE_HOSTNAME env var to override local service host#4947
feat: add SUPABASE_HOSTNAME env var to override local service host#4947
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Central YAML (base), Organization UI (inherited) Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (3)
📝 WalkthroughSummary by CodeRabbit
WalkthroughThe changes add support for a new SUPABASE_HOSTNAME environment variable to allow users to override the hostname used when the CLI runs inside a dev container with Docker socket bind-mounted. The GetHostname function in internal/utils/misc.go is updated to check this environment variable first, and if set, returns its value; otherwise, it retains the existing logic of deriving the host from Docker.DaemonHost(). Documentation is added to advise users on setting this variable, and tests are added to verify the environment-based behavior of the GetHostname function. Tip Try Coding Plans. Let us write the prompt for your AI agent so you can ship faster (with fewer bugs). Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Coverage Report for CI Build 25005058980Coverage decreased (-0.005%) to 63.748%Details
Uncovered ChangesNo uncovered changes found. Coverage Regressions5 previously-covered lines in 1 file lost coverage.
Coverage Stats
💛 - Coveralls |
Allows the CLI to work correctly when run inside a dev container with the Docker socket bind-mounted. In that context 127.0.0.1 is the container's own loopback, not the Docker host. Set SUPABASE_HOSTNAME=host.docker.internal to reach sibling containers via Docker Desktop's host gateway without proxying the Docker socket. --- AI assistance: Claude Sonnet 4.6 in Pi Agent - Used to find root cause, propose fix options, draft code/test/docs. - I ran supabase start inside the dev container, confirmed all services healthy, reviewed/edited all code changes/text.
kanaka
force-pushed
the
kanaka/hostname-env-var
branch
from
bbceb86 to
b1eaa19
Compare
| if h := os.Getenv("SUPABASE_HOSTNAME"); h != "" { | ||
| return h | ||
| } |
There was a problem hiding this comment.
nitpcik
Naming is broad I think SUPABASE_HOSTNAME reads like it could refer to the hosted Supabase API or remote project hostname. Something like SUPABASE_LOCAL_HOSTNAME or SUPABASE_DOCKER_HOST more precisely scopes it to local-services networking and is harder to misuse.
There was a problem hiding this comment.
@avallete Happy to rename this to make it more clear. SUPABASE_LOCAL_HOSTNAME and SUPBASE_DOCKER_HOST aren't quite right because this value is the opposite of that: it is an override for where to communicate with the supabase services when they don't live at localhost (i.e. they are not reachable at the same location as the docker host).
Richer context: right now the supabase service host location and the docker socket host location are same concept. I added this so that the CLI can communicate with the supabase services at a separate location from where the docker control socket lives. My concrete case is running an LLM agent in a container that has the host's docker socket mounted into that container. The sibling containers for supabase service are started via the docker control socket, but then the command tries to connect to localhost to reach the supabase services to check project health. That fails because localhost inside the LLM agent container is not where the supabase services are listening (they have ports bound to the host's localhost, not the LLM agent container's localhost). In theory, you actually could set SUPABASE_HOSTNAME to a remote location (although I haven't tested that specifically).
Maybe SUPBASE_SERVICES_HOSTNAME or SUPABASE_HOSTNAME_OVERRIDE?
3 participants
Allows the CLI to work correctly when run inside a dev container with the Docker socket bind-mounted. In that context 127.0.0.1 is the container's own loopback, not the Docker host.
Set
SUPABASE_HOSTNAME=host.docker.internalto reach sibling containers via Docker Desktop's host gateway without proxying the Docker socket.AI assistance: Claude Sonnet 4.6 in Pi Agent
What kind of change does this PR introduce?
Feature
What is the current behavior?
If
supbase startis run from a sibling container (e.g. with /var/run/docker.sock mounted from the host), the command is unable to connect to the those containers after starting them in order to do health checks:What is the new behavior?