/api/* routs always return 500
Hello i have tried to host supabase locally everything seems to be working except from supabase studio i keep getting 500 errors on /api/* routs which cause almost everything there to not function.
i have tried to setup everything such that the connections string rather than being kong:8000 swapped it to localhost:8000
in environment variables but still the same issue.
also tried recreating anon and service keys. but still same issue.
am not sure if it is an issue of used services but here is my docker compose
EDIT: deployment is done through coolify
172 Replies
Acc. to your compose file,
SUPABASE_URLenv passed to studio service needs to be http://supabase-kong:8000
make sure to recreate studio container for changes to take place and refresh page in browserit was as such i believe and i changed it but still doesn't work
am going to try again now.
No it isn't the default. You have changed the kong service name and acc.to that the value needs to be what I mentioned above
am deploying through coolify, defaults are alittle different.
just all services and their connection strings are renamed to supabase-*
Please always mention how you're self-hosting in original post. The value I mention should work but if you want to modify it later, you can use the randomized pattern they use
same issue
Did you take down studio and up again?
on all services.
i did click on coolify "stop"
and then "deploy" again
am assuming it is doing the same
you can inspect the running container's env vars just to be sure
Run
docker ps --format={{.Names}} | grep studio
yup it is there
Let me test it on my end. will get back to you
when going inside the container and using
env or printenv i see none of the variable
is this expected ?I have a old studio img version and I see envs are printed. Haven't tested with the image version you're using
i can test with it, which one are you using ?
i just copied the versions from supabase/docker github
its quite old on my local system
supabase/studio:2025.08.04-sha-6e99ca6
@Artist201 Oh wait
I think I found the issueo,o
just confirming!
btw i just tested your studio version
tables are working but the storage page isn't
I looked at your screenshots, the api routes you face error on use
STUDIO_PG_META_URL.
Its something to do with the latest img version you're using because in the newer version of studio, it passes a connection string to pgmeta and I'm guessing the request is going to pgmeta service something is happening there. I'm setting up a coolify instance.though it seems like an issue in the bucket
When setting up your project on coolify, did you only update the image versions or something else as well? I'm trying to reproduce error.
hmmmm
recreated my JWTSECRET and anonkey, servicekey
and change the docker compose kong version and setup user as root otherwise it never functions ( wasted 2 days on this )
added port expose on kong ( you should just copy my whole kong service )
i think that's it
I will use the coolify template and match your image versions
alright i hope kong works X_x
also am not sure if there is any need for recreating the secret and keys
also be aware if you are using coolify with remote host not running as root you might face an endless number of permissions issues.
if it is a local setup (coolify and the hosting server are on the same machine) all should be good
i recreated everyhing to test the buckets
seems to be working
upload though fails but probably cause it is trying to use a domain rather than the IP so now am trying to give the site a domain and see if it functions properly
This is with old studio, right?
yes your version
It should work with ip as well.
Make sure your
SUPABASE_PUBLIC_URL env var is set to the ip address you're accessing studio on
In coolify environment variables, its this env SERVICE_URL_SUPABASEKONGYeah its related to what I mentioned here
In newer versions studio sends a db connection string to pgmeta service
and it can't connect to db with the default values
yeah am seeing this weird thing in coolify
Its the domain coolify sets up instance on by default.
You're running this locally, right?
you're accesing this on an ipaddress like 192.x.x.x:8100?
nevermind, saw your screenshot
yeah it is just using the wrong env
so am just changing the compose no to reflect that
waiting for it to deploy
this
SUPABASE_PUBLIC_URL needs to be your ip
This however is not the solution to your original problem
its only your storage solutioninteresting.. but why X_x
yup
the newer version doesn't work
btw setup dozzle when reading logs it will make your life easier .. 😄
I've used it in past but I usually use lazydocker. Don't have to switch between windows
I'll explain this just checking if the solution I am applying works
@Artist201 Add these env vars in studio service
This should solve your issue with latest studio version
Explanation: https://github.com/supabase/supabase/issues/39593#issuecomment-3484722959
https://github.com/supabase/supabase/issues/39593#issuecomment-3485343711
And this was the PR: https://github.com/supabase/supabase/pull/40169
Nice ! thanks alot !
gonna try this after i resolve the upload issue X_X even after fixing the domain it still fails but fails weirdly
there is no response code
Check your browser's local storage if there are failed upload entries present
it usually stores them and tries to upload to the url which failed previously
Is the upload being made to the old url again?
no
the new one
which am accessing from
share a screenshot
oh i thought i sent it
it doesn't even show the used method
very weird...
postman
And what happens when you make request from browser directly in url input? Does it show
404?this
directly in url input. Not a fetch request.
same
if postman can correctly make request, don't know why browser can't
Weren't you accessing this project with ip address?
have you set entries in hosts file?
my machine have a cf tunnel
so i just gave it a domain to test what production issues i might have and am testing from it
everything is working except the upload
wait my env variables might be bugged let me test something
Could it be a CORS issue?
That would explain why it is passing in postman but not on browser
in the browser and post man it gives the same result except from that fetch returns nothing
shouldn't be cors thoguh cause it is the same domain
oh ok, I thought you only set tunnel url for env var
But in the postman, you do get route not found. That means the request is reaching
yeah...
i should have looked at the console
can you upload ?
hmmmm
maybe updating the studio will fix it ? idk
Make sure to add those new env vars for pg-meta queries to work
ahhhhhhhhhh... http/https issue
cause cf give me domain https by default but the url is in http
that is why it keeps failing
I was going to ask you about that but I thought maybe url is supposed to be http
well it is xD
how to update only the upload url thoguh ...
i can set up ssl but it gonna take a minute
which upload url?
this
This url is created using
SUPABASE_PUBLIC_URL so in your env vars just update the value
for example: https://example.com or whatever you're accessing your studio onit won't work as when it reaches coolify proxy it will se there is not any "https" certs since it is on local machine
i guess i will set it up
on what url are you accessing studio locally?
the one in your original screenshot (192.x.x.x:8100) or some other?
yeah
so why not simply use
192.x.x.x:8100?but adding localhost/ip doesn't work properly from coolify interface as far as remember
as when i put the url i have to say
mydomain.com:8000 and not mydomain.com:8100I am not aware of any issues with coolify on this so can't say
dw about it i have been fighting with it for a few days now
xD
acc. to your docker-compose, you're exposing kong on 8100:8000 and going by the screenshot you added in the original post, in your
SUPABASE_PUBLIC_URL you can add https://192.x.x.x:8100. I believe this should worki tried it before, idk why it didn't work. did the domain bugout ( it keeps happening with supabase installation idk why) or a proxy issue.
anyway
i settedup http and here we go !
last step let me update studio
oh btw edge function service broke down idk why xD
it broke after i changed the url
Changing SUPABASE_PUBLIC_URL shouldn't have any effect on functions service
Try restarting it. Maybe one time issue.
You didn't change any other config for this?
Volumes or command?
yeah nothing
also does the logs page work for you ?
or is it not supposed to be working for the self-hosted version
It does work. I can test it later. Away from pc right now
alright ty alot for your help ❤️
?
this is the error from the logs page
^
and many other 500 when you query
i thought it was working on the old studio version
let me switch back and check
Ok, will take a look.
I believe it must be an issue with env vars again
btw the one working fully for you is my compose ? or coolify template with just versions upgrade ?
I didn't check the logs page.
It was coolify template with version upgrade.
+ new env vars in studio
Btw, i noticed you have added open ai key as well. If you plan to use AI in studio, make sure to use this studio version https://github.com/supabase/supabase/issues/39664#issuecomment-3575914835
old studio version
but all requests are resolved
yeah kinda exited a little bit about that one
so i noticed there was a change in envs as the
LOGFLARE_API_KEY is depreciated and there is now public and private key.
swapped them and made a new deployment. (the previous edge functions issue resolved itself on new deployment)
as for the studio after adding the keys and removing LOGFLARE_API_KEY still not resolvedDid you add
LOGFLARE_PUBLIC_ACCESS_TOKEN and LOGFLARE_PRIVATE_ACCESS_TOKEN token in both studio and analytics?
Edit: I also had to add these values in environment variables
Also in vector service, you have to add LOGFLARE_PUBLIC_ACCESS_TOKEN https://github.com/supabase/supabase/blob/8de52c4eb3184bf3480e70073e2a60a06555f983/docker/docker-compose.yml#L477-L478
And you will also need to update vector.yml file. I'm testing it now and will send you in a few minutes
After this take down containers and up again. Now logs show up
i did everything except the vector, let me check it
i am receiving this in analytics
i was receiving this before thoguht the service continue normally but now it cause the other services not to start...
Did you update the entire vector.yml file in persistent storage tab?
And are you still on the same analytics version as the compose file you added above?
supabase/logflare:1.22.6yes, i just extended the health check time and it is passing and starting
however..
still the logs page doesn't work
share your updated compose file
i found a typo
redeploying...
There is one on line 144. Is that the one you found?
the double brackets
yeah
i hate how coolify just deploys now an older version of your compose and doesn't tell you yours is broken -_-
I wasn't even aware of this behavior. Thanks for letting me know. I don't use it regularly.
You can run
docker compose config at the location where coolify is storing these files.this will validate ?
yeah
yaaay
except the
/api/platform/organizations/default-org-slug/entitlements
I believe this is some api which only needs to be called on hosted platform.
the proxy bugged again so i used my local IP
X_x
hmmm so you get the same behavior ?
yeah it works absolutely fine with ip address/domain locally. did you also try uploading to storage with SUPABASE_PUBLIC_URL set to this ip?
Haven't tested this with this latest image.
But I believe it should be same. This api request is being made from studio itself. Also usually 404 errors in studio indicate resources which are only supposed to be called on hosted
no i didn't try with the IP
iam trying to make it work with the domain now to test it again.
if that succeeds i will test with the IP
I've tested it before and it does work. Just wanted to confirm if its working on your end.
btw you are running on a cloud server and everything worked fine, coolify installed locally on that server right ?
yes, coolify and supabase were on same server
just confirmed even on a domain, same issue for the entitlment path
when you said for "hosted" did you mean their commercial deployment ?
though everything seems to be working normally
though it some times does this
i shouldn't see this page >.>
alright here we go again X_x
i down graded to my original compose studio version
the current one they put for the AI stuff is broken and shows some menues from the commercial supabase
in term of GUI everything seems to be working now
i noticed 2 things idk if they are supposed to be like this.
1- i can't reset the DB password
2-there is no pooler connections string
i think this whole settings page is broken anyway
i noticed in your old studio image i can't even access the settings page.
nor do i see the pooler connection option.
and noticed this env var missing from environments variables
even in their github repo
Logdrains are supported on selfhosted. It was added recently.
Yes you can't make any configuration changes from studio
And you won't see updated env vars on studio.
Its not supposed to work on selfhosted. you won't see any updates on studio
@inder what about the pooler ?
if the container is healthy, its running, but you won't see any updates and you can't make any config changes from studio
so it is available but the studio don't show it at all
yes, not just for pooler you can't make any config changes for any service for example: auth etc.
From self-hosted studio, you can only do db operations like sql queries, add/delete users, enable/disable extensions and storage uploads
eah...
and changing just the env vars for db password for example will break things so i have to do it through container shell, right ?
yes for changing password refer to this https://discord.com/channels/839993398554656828/1442218138602180638/1442245235454247008
no no no.. i won't reset all my data for a password change
postgress password should changable through the container postgress shell
I have mentioned two ways in the link above
ah sorry
There is also a script linked in the gh comment. you can use that to automate this
and should be executed from supabase-db nice
alright now everything is running yaaay
is it safe to just remove
supabase-auth and supabase-edge-function service ? as am not going to use them for now and i can save some resources.yes its safe if you're not using them. You can also remove logs service as you're only running things locally
analytics and vector
i probably shouldn't
this local deployment is for testing i have my server
what about this ?
and the supabase-rest service as a whole
auth and edge-function are light. If you want to really save resources on your test machine, then logs is something you need to remove and enable it in production
This is what exposes your db as API endpoints
oh right it is
postgress://authenticator
i thought it was http
any way sorry i toke alot of your time T_T
THANK YOU !no worries!
and for the record the current version that should support open-ai key of the studio is kinda broken and shows stuff from commercial supabase and hides the log drains and many more issues
supabase/studio:2025.08.04-sha-6e99ca6 this seems like the latest working one ( not sure about the AI stuff but works otherwise )The one which was mentioned in the comment is broken? Just to be sure can you paste the version
can you also add some screenshots
alright.. my vm network connection is slow so give me some time xD as the cash just restted
2025.08.04-sha-6e99ca6 works perfectly
2025.11.10-sha-5291fe3 works perfectly but shows you the settings page and the pooler connections option (otherwise everything works)
2025.11.24-sha-d990ae8 super messyOn the latest one, do AI features work? It was supposed to fix a small issue overriding a header
i will check when testing the latest one
btw can you share your compose
i am surprised kong worked for you without setting up the user to be root
I didn't make any other change except the versions + new env vars.
And if I remember correctly, I didn't change kong version.
So maybe in v3, they made some change internally
I checked the latest version. And yeah logdrains destinations are not shown. Was there any other issue?
sorry the VM is too Slow T_T
and settings page/connection string showing the pooler
as far as i remember
This?
yeah
You can ignore this. Its supposed to not work. Maybe they will hide this page in the future.
yeah there are many of those e.g.
hmm, looks like there is an active PR where they're hiding these pages on self-hosted
when connecting using connection string
and for the pooler just change the port to 6543 ?
postgresql://postgres:[YOUR_PASSWORD]@127.0.0.1:5432/postgres
the 127.0.0.1 will be the same studio domain ?and for the pooler just change the port to 6543 ?
postgresql://postgres:[YOUR_PASSWORD]@127.0.0.1:6543/postgres
cause coolify doesn't seem to allow enabling 2 ports to be public X_xYes the 127.0.0.1 will be the studio domain but the url is different and meaning of ports is different
First when you connect via pooler, the url needs to be like this
This <POOLER_TENANT_ID> is present in your env vars. Take a look in your environment variables. If not present there, it must be present in supavisor service.
Regarding ports refer to these docs for when to use which port: https://supabase.com/docs/guides/database/connecting-to-postgres#poolers
This is from your original compose file
Also, I don't think coolify will block you to expose ports. If you're getting some error, then check if some other service is already exposed on that port
the domain automatically resolves to port 8000
thus it doesn't work i just verified that.
currently i can only connect with the IP which i don't really like...
thank you for the pooler info and yeah i probably will need to switch the port.
but are all connections supposed to go through the studio or am supposed to connect directly to the supabase-db ? am trying to setup some proxy settings to allow traffic
no, all connection go through kong. The domain you see points to kong
You will have to make direct connection to db. point your domain to server and connect on port 5432 or 6543 depending on your use case
am confused now.
am i supposed to connect to my db through kong or directly
What I meant was that everything except direct db connection go through kong
and the pooler is still direct right ?
connecting to port
5432 and 6543 should be directly to supabase-db that is what i understand nowTechnically it is. But in postgres terms, a direct connection will be when connecting on port 5432.
on port 6543, its in transaction mode
yeah no worries about that i just meant the connection should go directly toward the database
now it is a simple task of just giving it a domain.
yes, you can use the same domain you were planning to use for supabase or use a subdomain. That doesn't matter