Issues connecting to local Supabase DB on Local AI

[NachoT]

Hello People:

Great community we have here and a lot of toys to play with

Not really sure if Archon is the right place to post this issue I have or if it should go to Local AI. Please move it if needed.

Since I have the Local AI stack running locally I wanted to use Archon v6 with the local Supabase install. It runs on an Apple Silicon Mac.

In the Archon Environment I configure Ollama and the models fine but I think I have issues with the Database.

That is the address I point to and the Key is SERVICE_ROLE_KEY from .env (the screenshot is from .env.example)

The thing is that in the next step I get this error: “Error checking table status: [Errno 111] Connection refused” both before and after running the SQL query.

Now, for the life of me I cannot find how to track this error or where to look. Archon does not display any error in the logs, and in the Local AI stack I’ve checked every container in the stack but cannot find anything.

Just so you know, the Local AI stack works flawlessly.

Also, on a side note, @ColeMedin I was expecting an error in when crawling the Pydantic documentation. The fetching and digesting of the info goes fine, but if it cannot write to the DB, it should either stop or print the error on the screen. But neither happens and one may think the info is on the DB when it is not.

Anyhow, many thanks for reading up to this point. If you know how to help, I’d very much appreciate it.

Regards,
Nacho

[patkelman]

I set it up yesterday with a similar setup, and it populated the database, but when i restarted my local ai, suddenly i started getting the same error as you.

[patkelman]

@NachoT I had to go into my Authentication settings and disable RLS for the site-pages table. When I restarted the service, all was good.

[NachoT]

Many thanks @patkelman for the suggestion. I did find the place you mention and disabled RLS. It was the only setting there that was enabled, by the way.

Then restarted both Local AI and Archon containers but still got the same error: “Error checking table status: [Errno 111] Connection refused”

Any idea which of the Supabase containers is the one that may receive the request? Not sure how to track the flow of info.

[ColeMedin]

That’s strange you had to do that! Were you maybe using the anon (public) key instead of the service role key for Supabase within Archon?

[ColeMedin]

Could you try taking /project out of the Supabase URL?

[NachoT]

Thanks @ColeMedin for looking into this.

Yes, the /project was there as a test. I’m no longer using that, only http://localhost:8000. It makes no difference.

Also, using both keys, Anon or Service, curiouslyI get the same error. If I use a made up one (ex: 1234) then I’m asked to set the environment properly.

I’ve even tried setting the .env. It does not populate the data in the Archon Environment webpage, but going to the Database part shows the same error.

This screenshot is just to show that .env file, environment of the Archon container and the actual configuration of Supabase do match on for the Service Key.

So I’m starting to think it is the way Archon processes/presents the Key to Supabase that changes something. Or that Archon/Supabase do not understand each other or something like this.

[poezie]

So to close the loop here I went to the python install over the docker , and also removed RLS. Once I did this all my issues went away and suddenly it all worked as intended. Thanks

[NachoT]

Thanks for replying @poezie, but your reply has been a little too cryptic for me.

If you could elaborate a little bit more so I can follow your steps.

Not sure how to remove RLS on the python install on docker.

[NachoT]

Hi all:

Finally after many test and trials I’ve been able to crack this.

The key was not the keys… but the URL!

I have ollama running external to docker, where is everything else: local AI package and Archon.

Does not matter the service, all the addresses have to be host.docker.internal:port:

• Ollama → http://host.docker.internal:11434/v1
• Supabase → http://host.docker.internal:8000

The worst part of learning is not knowing what one may know but not knowing what one does not know and I definitely do not know when is localhost and when is host.docker.internal.

Thank you all for the help

[ColeMedin]

Thanks for circling back on this and I’m really glad you figured it out!

[patkelman]

Brilliant thank you!