Self hosted Supabase - support self signed certification connection #855
Conversation
WalkthroughThis PR modifies the docker-compose configuration to introduce a dual-network architecture. An external network called Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes
Poem
Pre-merge checks and finishing touches❌ Failed checks (2 warnings)
✅ Passed checks (1 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
docker-compose.yml(1 hunks)
🧰 Additional context used
🪛 YAMLlint (1.37.1)
docker-compose.yml
[error] 1-1: wrong new line character: expected \n
(new-lines)
| # Docker Compose profiles: | ||
| # - Default (no profile): Starts archon-server, archon-mcp, and archon-frontend | ||
| # - Agents are opt-in: archon-agents starts only with the "agents" profile | ||
| # Usage: | ||
| # docker compose up # Starts server, mcp, frontend (agents disabled) | ||
| # docker compose --profile agents up -d # Also starts archon-agents | ||
|
|
There was a problem hiding this comment.
YAML formatting issue: incorrect newline character.
The file should use LF (Unix-style) line endings instead of CRLF.
🧰 Tools
🪛 YAMLlint (1.37.1)
[error] 1-1: wrong new line character: expected \n
(new-lines)
🤖 Prompt for AI Agents
In docker-compose.yml around lines 1 to 7, the file currently uses CRLF
(Windows) line endings instead of LF; convert the file to Unix-style LF line
endings (e.g., run dos2unix docker-compose.yml or change your editor to use LF
and save) then recommit the file; ensure your git settings won't reintroduce
CRLF (set core.autocrlf=false or configure .gitattributes to enforce LF for YAML
files) before pushing.
| networks: | ||
| - app-network | ||
| - localai_default | ||
| volumes: | ||
| - /var/run/docker.sock:/var/run/docker.sock # Docker socket for MCP container control | ||
| - ./python/src:/app/src # Mount source code for hot reload | ||
| - ./python/tests:/app/tests # Mount tests for UI test execution | ||
| - ./migration:/app/migration # Mount migration files for version tracking |
There was a problem hiding this comment.
🧩 Analysis chain
Critical mismatch: PR title mentions self-signed certificate support, but no SSL/TLS configuration is present.
The PR is titled "Self hosted Supabase - support self signed certification connection," but the changes do not include any environment variables or configuration to handle self-signed SSL certificates (e.g., SUPABASE_SSL_VERIFY=false, REQUESTS_CA_BUNDLE, or certificate path mounts).
Currently, SUPABASE_URL (line 21) is passed without any SSL verification overrides, which will fail when connecting to a self-hosted Supabase instance with a self-signed certificate.
Additionally, the Docker socket mount (line 36) adds a significant security surface—the container can now control all other containers on the host. Clarify:
- Why the Docker socket is necessary (appears unrelated to self-signed certificates).
- Whether the external
localai_defaultnetwork is intended for LocalAI integration or Supabase.
I'll verify the review comment by examining the docker-compose.yml file in full, checking for SSL/TLS configuration, and understanding the PR context.
---
🏁 Script executed:
```shell
#!/bin/bash
# Retrieve PR title and description
gh pr view --json title,body,files -q '.title, .body' 2>/dev/null || echo "PR context not available"
Length of output: 24
🏁 Script executed:
#!/bin/bash
# Examine full docker-compose.yml
find . -name "docker-compose.yml" -o -name "docker-compose.yaml" | head -5 | xargs -I {} sh -c 'echo "File: {}"; cat "{}"'Length of output: 6197
🏁 Script executed:
#!/bin/bash
# Search for environment variable files
fd -e env -e "env.*" . | grep -E '\.(env|yaml|yml|json)' | head -20Length of output: 0
🏁 Script executed:
#!/bin/bash
# Search for SSL/TLS related configuration
rg -i 'ssl|tls|certificate|cert|verify|supabase.*ssl|requests_ca|ca_bundle' -n --type yaml --type json --type env . 2>/dev/null | head -30Length of output: 0
🏁 Script executed:
#!/bin/bash
# Look for environment variable definitions related to Supabase
rg -i 'supabase_url|supabase.*ssl|supabase.*verify' -n -B2 -A2 . 2>/dev/null | head -40Length of output: 2049
---
🏁 Script executed:
```shell
#!/bin/bash
# Look for .env.example or template files
fd -type f -name ".env*" -o -name "*example*" . 2>/dev/null | head -20
Length of output: 0
🏁 Script executed:
#!/bin/bash
# Search Python code for SSL/certificate verification handling
rg -i 'ssl|tls|verify|ca_bundle|cert|self.?signed' --type py -n -B2 -A2 . 2>/dev/null | head -50Length of output: 4102
🏁 Script executed:
#!/bin/bash
# Check for README or setup documentation mentioning SSL/self-signed
rg -i 'self.signed|ssl.*supabase|supabase.*ssl|certificate' --type md -n -B2 -A2 . 2>/dev/null | head -40Length of output: 0
🏁 Script executed:
#!/bin/bash
# Search for git log or recent changes related to SSL/certificate
git log --all --oneline --grep -i 'ssl\|certificate\|self.signed' 2>/dev/null | head -20 || echo "Git history not available"Length of output: 0
🏁 Script executed:
#!/bin/bash
# List recently modified files to understand PR scope
git diff --name-only HEAD~5..HEAD 2>/dev/null || find . -name "*.py" -o -name "*.yml" -o -name "*.yaml" | grep -E '(supabase|config|env)' | head -20Length of output: 274
---
🏁 Script executed:
```shell
#!/bin/bash
# Examine .env.example for SSL/certificate variables
cat .env.example
Length of output: 5880
🏁 Script executed:
#!/bin/bash
# Check config.py for Supabase and SSL configuration
cat python/src/server/config/config.pyLength of output: 10141
🏁 Script executed:
#!/bin/bash
# Search for Supabase client initialization in Python code
rg -i 'supabase|create_client' --type py -n -B3 -A3 . 2>/dev/null | head -60Length of output: 4474
🏁 Script executed:
#!/bin/bash
# Check README for self-hosted Supabase or SSL instructions
cat README.md | grep -i -A5 -B5 'self.hosted\|supabase\|ssl\|certificate' || echo "No SSL/Supabase docs found in README"Length of output: 2918
---
🏁 Script executed:
```shell
#!/bin/bash
# Examine client_manager.py to see Supabase client instantiation
find . -name "client_manager.py" -type f | head -1 | xargs cat
Length of output: 1085
🏁 Script executed:
#!/bin/bash
# Search for supabase.create_client calls and SSL/verify options
rg -i 'create_client|Client.*supabase' --type py -n -B5 -A10 . 2>/dev/null | head -80Length of output: 7475
SSL/TLS configuration is missing—PR title does not match implementation.
Verification confirms the review comment's concerns:
-
No self-signed certificate support:
docker-compose.ymlcontains no SSL environment variables;.env.examplehas noSUPABASE_SSL_VERIFY,REQUESTS_CA_BUNDLE, or certificate path options;config.pyprovides no SSL override mechanism;client_manager.pycallscreate_client(url, key)without any SSL parameters. -
Docker socket mount confirmed (line 36):
/var/run/docker.sock:/var/run/docker.sockis present with comment "Docker socket for MCP container control"—a security surface that requires justification. -
External network usage confirmed:
localai_defaultis an external network used across all services (archon-server, archon-mcp, archon-agents, archon-frontend) for service-to-service communication.
To support self-signed certificates for self-hosted Supabase instances, add SSL verification configuration:
- Environment variables (e.g.,
SUPABASE_SSL_VERIFY=falseorREQUESTS_CA_BUNDLE=/path/to/ca.pem) to.env.example - SSL handling logic to
config.pyandclient_manager.pyto pass SSL options to the Supabase client - Documentation in
README.mdexplaining self-hosted Supabase SSL setup
Clarify the Docker socket mount necessity and confirm localai_default network intent before merging.
🤖 Prompt for AI Agents
In docker-compose.yml around lines 32 to 39 (where networks and volumes are
defined, including the Docker socket mount), the PR lacks SSL/TLS configuration
for self-hosted Supabase and leaves an unclarified docker socket mount and
external network usage; add environment variables to .env.example (e.g.,
SUPABASE_SSL_VERIFY and REQUESTS_CA_BUNDLE or a CA_PATH), update config.py to
load these env vars and produce an SSL/requests CA bundle option, modify
client_manager.py to accept and pass SSL/verify or CA path into the Supabase
client creation call (create_client) so client connections can use a self-signed
CA or disable verification when explicitly configured, update README.md with
instructions for configuring self-hosted Supabase SSL (how to set
SUPABASE_SSL_VERIFY/REQUESTS_CA_BUNDLE and where to place certs), and in
docker-compose.yml either justify/remove the /var/run/docker.sock mount or add a
comment explaining why it is required and verify that using the external network
localai_default is intentional across services.
| networks: | ||
| - app-network | ||
| - localai_default |
There was a problem hiding this comment.
🧩 Analysis chain
External network localai_default must be created in advance or docker-compose will fail.
All services now depend on the external localai_default network (line 186), but this network is not created automatically by Docker Compose when marked external: true. Users must manually create it beforehand:
docker network create localai_defaultAdd clear documentation or a setup script, or reconsider whether this network should be created by Compose rather than external.
Also clarify why a dual-network architecture is needed. The rationale for adding localai_default alongside app-network is not documented and appears disconnected from the PR objective (self-signed certificate support).
Also applies to: 92-94, 136-138, 168-170
I'll verify the review comment by examining the docker-compose.yml file and checking the network configuration claims.
🏁 Script executed:
#!/bin/bash
# Examine docker-compose.yml to verify network configuration
if [ -f "docker-compose.yml" ]; then
echo "=== Full docker-compose.yml content ==="
cat docker-compose.yml
else
echo "docker-compose.yml not found at root"
find . -name "docker-compose.yml" -o -name "docker-compose.yaml" 2>/dev/null | head -5
fiLength of output: 6210
I need to check for documentation, setup scripts, and context about the certificate support mentioned in the review.
🏁 Script executed:
#!/bin/bash
# Search for documentation, setup files, and references to localai_default and certificates
echo "=== Looking for setup scripts ==="
find . -maxdepth 2 -name "*.sh" -o -name "setup*" -o -name "README*" -o -name "*.md" | head -20
echo -e "\n=== Searching for localai_default references ==="
rg -n "localai_default" --type yaml --type txt --type md 2>/dev/null
echo -e "\n=== Searching for certificate/SSL references ==="
rg -n -i "certificate|ssl|tls|self-signed" --type yaml --type txt --type md 2>/dev/null | head -30Length of output: 3569
🏁 Script executed:
#!/bin/bash
# Check for PR-related files and git context
echo "=== Looking for PR description or commit context ==="
ls -la .github/ 2>/dev/null | grep -i pull
echo -e "\n=== Checking README.md for deployment/setup instructions ==="
head -100 README.md | grep -i -A 5 "docker\|setup\|network\|localai"
echo -e "\n=== Checking if there's any Python code using localai_default ==="
rg -n "localai_default" . --type py 2>/dev/null
echo -e "\n=== Checking for any environment or config files mentioning networks ==="
find . -name ".env*" -o -name "config*" | head -10Length of output: 650
🌐 Web query:
What is LocalAI and why would it require a separate Docker network?
💡 Result:
Short answer
- LocalAI is an open‑source, OpenAI‑compatible local inference server that lets you run LLMs, image/audio models and an OpenAI‑style REST API on your own hardware. [1]
- A separate Docker network is commonly used so LocalAI and other containers (UIs, model backends, plugins like AnythingLLM, or optional GPU runtimes) can communicate securely and reliably without exposing services to the host or colliding ports. It enables cross‑compose service discovery by name, network isolation, custom bridge settings (e.g., bind to 127.0.0.1), and avoids port conflicts when running multiple stacks. [1][2]
Why you’d add one (concise list)
- Service discovery: containers find each other by name across compose files. [2]
- Isolation & security: keep LocalAI traffic off the host network or public interfaces (bind to localhost). [2]
- Avoid port collisions: multiple stacks can share an internal network while only chosen ports are published.
- Flexible driver/options: set bridge/host_binding_ipv4, attach external containers (GPU runners, AnythingLLM) to the same network. [2]
Sources
- LocalAI official site. [1]
- Example/how‑to notes showing adding a dedicated Docker network to LocalAI docker‑compose for connecting other containers (AnythingLLM / UIs). [2]
External localai_default network requires setup documentation or script.
The review comment is correct and identifies a critical issue. The localai_default network is marked external: true at line 186, and all four services (archon-server, archon-mcp, archon-agents, archon-frontend) reference it, but no setup instructions or script exist to create it beforehand. Without the network, docker-compose up will fail immediately.
Additionally, the dual-network architecture (both app-network and localai_default) lacks any documentation explaining its purpose or rationale. While LocalAI commonly uses separate Docker networks for service discovery and isolation, this codebase appears designed to integrate with or depend on LocalAI infrastructure, yet provides no guidance to users on setup.
To resolve: add a setup.sh script or update deployment documentation to include docker network create localai_default, or reconsider marking the network external if it should be managed by Compose.
🤖 Prompt for AI Agents
In docker-compose.yml around lines 32 to 34 (and note the external: true
declaration at ~line 186), the compose references an external network
localai_default but provides no setup or documentation, causing docker-compose
up to fail; fix by either adding a setup script (e.g., scripts/setup.sh) that
runs docker network create localai_default and is referenced in deployment docs,
or remove the external flag and let Compose create the network, and update
README/deploy docs to explain the dual-network design and why localai_default is
required and how to create it (include the exact docker network create command
and when to run the script).
|
@Hidden-History could you please comment on what change you made and why, was something broken when using the local package? |
|
when running achon with the local ai package on localhost, I was getting the same issues as found in archon, Self hosted Supabase - support self signed certification connection #596, #596, this fixes that issue with localhost, i do not have the cloud service to test to see if this has any effect on that type of intall, or on a VPS etc, this fixed this issue for me on localhost* |
2 participants
Pull Request
Summary
Self hosted Supabase - support self signed certification connection fix
Changes Made
##I have not tested if this messes with the cloud service, I am using coles local ai package with Archon.
Step 1: Connect Docker Networks
Archon and Supabase need to share a Docker network to communicate.
File:
/archon/docker-compose.ymlAdd the external network and connect all services:
Step 2: Update Archon Supabase URL
Archon needs to connect to Supabase using the Docker service name, not
host.docker.internal.File:
/archon/.envChange:
To:
Step 3: Allow HTTP for Kong Hostname
Archon's security config requires HTTPS for non-localhost URLs. We need to whitelist "kong".
File:
/archon/python/src/server/config/config.pyFind line ~110 and modify:
Step 4: Restart Services
Start Supabase first, then Archon:
Type of Change
Affected Services
Testing
Test Evidence
docker compose logs -f # All services
no errors
Checklist
Breaking Changes
Additional Notes
Step 4: Restart Services
Start Supabase first, then Archon: