What is the purpose of PUBLIC_ORIGIN or PUBLIC_HOST? #856
-
I'm trying to run teable CE locally using docker compose. My configuration includes local redis and local docker minio. My env file is not changed from the docs. Unsurprisingly, I am getting a 500 error when trying to register as a new user because it is trying to connect to 192.168.x.x (the default value for PUBLIC_HOST in the docs) which doesn't exist. Clearly I need to modify PUBLIC_ORIGIN and PUBLIC_HOST, as indicated in the docs. But what should I modify these values to be? I want my entire setup running locally. My understanding of teable is that I should be able to do this. I don't want any external network connections (incoming or outgoing). It seems natural to me to use localhost or 127.0.0.1 but this is said not to work in the docs. What is my misunderstanding? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 3 replies
-
Teable's deployment model requires using an external IP or domain name to access MinIO, rather than localhost or 127.0.0.1. This is because Teable needs to access the file service (MinIO) from both the server-side and client-side. The server uses MinIO's presignedUrl API to authorize file access, while the client directly accesses MinIO through signed URLs. In Docker containers, 127.0.0.1 always points to the current container, preventing Teable from correctly accessing MinIO. Although the server could use internal DNS (service name "minio") to access MinIO, this would generate presignedUrls with "minio" as the hostname, making it impossible for the client to access correctly. The current workaround is to use an external IP or domain name for MinIO access. If you prefer not to expose Teable to external networks, you can opt for Teable's built-in file service instead of enabling MinIO. We're actively exploring better solutions to address this issue. |
Beta Was this translation helpful? Give feedback.
Teable's deployment model requires using an external IP or domain name to access MinIO, rather than localhost or 127.0.0.1. This is because Teable needs to access the file service (MinIO) from both the server-side and client-side. The server uses MinIO's presignedUrl API to authorize file access, while the client directly accesses MinIO through signed URLs. In Docker containers, 127.0.0.1 always points to the current container, preventing Teable from correctly accessing MinIO. Although the server could use internal DNS (service name "minio") to access MinIO, this would generate presignedUrls with "minio" as the hostname, making it impossible for the client to access correctly.
The current…