Add docker socket mount path to config.toml

[Fractal-Tess]

Is your feature request related to a problem? Please describe.
The problem is that on rootless docker in Linux (In my case, I'm on nixos) the docker socket isn't in the default path of /var/run/docker.sock, but instead at /run/user/1000/docker.sock.

Describe the solution you'd like
Add an option to the config.toml file to be able to change the location of the mounted docker socket

Additional context
This concerns users on Linux running the supabase cli - since the vector service mounts the docker socket, it crashes when it's not able to.
I can probably name 4-5 issues + a bunch of discord issues regarding the issue of the vector service crashing because of the permissions os 13 error regarding this issue. A fix like the one above could potentially solve all of these.

[Fractal-Tess]

A friend of mine is open to adding this change in (PR) as we already have done this in a fork if people are interested.

[sweatybridge]

Does it work today if you set the DOCKER_HOST env var when starting supabase?

DOCKER_HOST=unix:///path/to/socket supabase start

I suspect a non-root socket is not trivial because we use dind for some containers, including analytics. But happy to review the change if you open a PR.

[Fractal-Tess]

We tested a bunch of things yesterday, and even though we didn't have much time to look into the code deeply, we believe there is a mistake in how it is being parsed. I'm not a go expert myself, but currently, the behaviour is that even though my shell's DOCKER_HOST env var is unix:///run/user/1000/docker.sock, the path that ends up being used is /run/var/docker.sock instead.

This is also the case if I run docker context inspect, it shows me the unix:///run/user/1000/docker.sock path.
We made a quick monkey patch to add the option for a dokcer_socket in the config.toml and use that for the socket path of the host instead.

I'm 99% sure the wanted behaviour is to just strip out the unix:// from the DOCKER_HOST environment variable of the shell and use that for the host socket, and always use /var/run/docker.sock for the container path.

[eaceaser]

FWIW things seem to be working for me w/ rootless Podman exposing a Docker-compatible socket if I disable analytics, so I think the issues are specific to that.

[Fractal-Tess]

And why do you think it works if you disable analytics? @eaceaser
Here is a log of what gets printed in my console using the supabase cli version 2.12.1

WARNING: analytics requires mounting default docker socket: /var/run/docker.sock

Should be pretty self-explanatory.

Adding more on your comment - yes, you are right about the cli successfully starting up the services if you disable the analytics service. But this should NOT be the intended behaviour and we should aim to fix this instead of using workarounds.
Also, even if you disable analytics, the supabase cli is all happy and gives off the illusion that everything has started up (of course without the analytics), however, if you do dokcer ps --all, you will see that the vector service has exited with an error.

As for the pr, I'll try to work on it tomorrow and make a submission for review. Hopefully we can get this sorted out so it becomes useable in its intended behaviour.

Thank you

edit - grammar

[eaceaser]

@Fractal-Tess vector doesn't start for me when I disabled analytics? are you sure that's not an old container that hasn't been cleaned up? Besides Vector, all containers / local behavior seem to be fine when using an alternative docker socket path as far as I can tell.

IDK why you think I'm implying that this shouldn't be fixed, I was just offering a workaround when I ran into this today considering that others may find this issue.

[Fractal-Tess]

@Fractal-Tess vector doesn't start for me when I disabled analytics? are you sure that's not an old container that hasn't been cleaned up? Besides Vector, all containers / local behavior seem to be fine when using an alternative docker socket path as far as I can tell.

IDK why you think I'm implying that this shouldn't be fixed, I was just offering a workaround when I ran into this today considering that others may find this issue.

Can you confirm the vector service starts up for you when you disable analytics and run supabase start ?

[eaceaser]

yes:

❯ grep -A1 analytics supabase/config.toml
[analytics]
enabled = false
❯ podman ps -a
CONTAINER ID  IMAGE       COMMAND     CREATED     STATUS      PORTS       NAMES
❯ supabase start
WARN: no seed files matched pattern: supabase/seed.sql
Started supabase local development setup.

         API URL: http://127.0.0.1:54321
     GraphQL URL: http://127.0.0.1:54321/graphql/v1
  S3 Storage URL: http://127.0.0.1:54321/storage/v1/s3
          DB URL: postgresql://postgres:[email protected]:54322/postgres
      Studio URL: http://127.0.0.1:54323
    Inbucket URL: http://127.0.0.1:54324
      JWT secret: super-secret-jwt-token-with-at-least-32-characters-long
        anon key: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZS1kZW1vIiwicm9sZSI6ImFub24iLCJleHAiOjE5ODM4MTI5OTZ9.CRXP1A7WOeoJeXxjNni43kdQwgnWNReilDMblYTn_I0
service_role key: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZS1kZW1vIiwicm9sZSI6InNlcnZpY2Vfcm9sZSIsImV4cCI6MTk4MzgxMjk5Nn0.EGIM96RAZx35lJzdJsyH-qQwv8Hdp7fsn3W0YpN81IU
   S3 Access Key: 625729a08b95bf1b7ff351a663f3a23c
   S3 Secret Key: 850181e4652dd023b7a98c58ae0d2d34bd487ee0cc3254aed6eda37307425907
       S3 Region: local
❯ podman ps -a
CONTAINER ID  IMAGE                                            COMMAND               CREATED         STATUS                   PORTS                                                       NAMES
a7a2a9f2f183  public.ecr.aws/supabase/postgres:15.8.1.020      postgres -c confi...  29 seconds ago  Up 29 seconds (healthy)  0.0.0.0:54322->5432/tcp                                     supabase_db_supabase-cli
9778b38abd50  public.ecr.aws/supabase/kong:2.8.1                                     17 seconds ago  Up 17 seconds (healthy)  0.0.0.0:54321->8000/tcp, 8001/tcp, 8088/tcp, 8443-8444/tcp  supabase_kong_supabase-cli
26267919344a  public.ecr.aws/supabase/gotrue:v2.167.0          auth                  17 seconds ago  Up 17 seconds (healthy)  9999/tcp                                                    supabase_auth_supabase-cli
496c869e2ebd  public.ecr.aws/supabase/inbucket:3.0.3           -logjson              17 seconds ago  Up 17 seconds (healthy)  0.0.0.0:54324->9000/tcp, 1100/tcp, 2500/tcp                 supabase_inbucket_supabase-cli
e845da6387cd  public.ecr.aws/supabase/realtime:v2.34.7         /app/bin/server       17 seconds ago  Up 17 seconds (healthy)  4000/tcp                                                    supabase_realtime_supabase-cli
f53f1f4173dd  public.ecr.aws/supabase/postgrest:v12.2.0        /bin/postgrest        17 seconds ago  Up 17 seconds            3000/tcp                                                    supabase_rest_supabase-cli
8dfb39edd3dd  public.ecr.aws/supabase/storage-api:v1.14.5      node dist/start/s...  17 seconds ago  Up 17 seconds (healthy)  5000/tcp                                                    supabase_storage_supabase-cli
1dd096b093ff  public.ecr.aws/supabase/edge-runtime:v1.67.0                           16 seconds ago  Up 17 seconds            8081/tcp                                                    supabase_edge_runtime_supabase-cli
83335129cdd2  public.ecr.aws/supabase/postgres-meta:v0.84.2    node dist/server/...  16 seconds ago  Up 16 seconds (healthy)  8080/tcp                                                    supabase_pg_meta_supabase-cli
37a9a6161598  public.ecr.aws/supabase/studio:20250113-83c9420  node apps/studio/...  16 seconds ago  Up 16 seconds (healthy)  0.0.0.0:54323->3000/tcp                                     supabase_studio_supabase-cli

edit: to be clear, it does NOT start up when analytics is disabled, hence the workaround

[Fractal-Tess]

Hum... yeah you are right. This is on me.

I swear to god that there was a vector service in an error exit state when I tested earlier - must have not cleaned up properly before testing - good catch!

Still, I believe this to be the cause of the docker socket, since after fixing this in the code and mounting the correct path, even with analytics and vector, it runs perfectly as intended.

[Fractal-Tess]

I've submitted a PR with the fixes that made my system work without a problem. Hopefully, this works on all unix-like machines, but I'm not certain.

I haven't introduced an option for adding the docker_host variable to the config file, but this could also be added if you think it will be helpful to have - I personally feel like it would be awesome for there to be a knob we can set explicitly and not really on some static implementation in case issues arise later on.

Anyway, let me know what you think @sweatybridge.

Thank you for your time.

[abn]

@Fractal-Tess thanks for the fix; I can confirm having DOCKER_HOST=unix:// works for me as well. In my case, I also needed #3150.

Regarding the docker_host config option, I would not think that is required as this is local to user's environment. Would be odd to have that in a shared config (assuming config.toml is intended to be shared).