Ability to provide custom self signed certificates

[jbojcic1]

Is your feature request related to a problem? Please describe.

I need to run my local Supabase with https enabled. My app uses some APIs that only runs in the secure context and when I am running the app on my machine and accessing it from the phone connected to same wifi I can't use localhost. Instead I need to use http://<my_hostname>.local:<port> and this is not considered secure context so those APIs don't work unless I run it on https://<my_hostname>.local:<port>. However when I do that my http calls to Supabase API are being blocked so I need to enable https for Supabase which I do by doing:

[api.tls]
# Enable HTTPS endpoints locally using a self-signed certificate.
enabled = true

But the problem is that Supabase certs seem to be only for localhost so I can't use it with my hostname.

Describe the solution you'd like

In Supabase config.toml it should be possible to do something like:

[api.tls]
# Enable HTTPS endpoints locally using a self-signed certificate.
enabled = true
# Use our mkcert certificates
cert_file = "../certs/my-cert.pem"
key_file = "../certs/my-key.pem"

That way I can make any cert I want and Supabase can use it.

Describe alternatives you've considered

The alternative I am considering to do now while this is not supported is to proxy all calls to Supabase through my server in the development mode. But even if I manage to make this work, it will be messy

Additional context

/

[jbojcic1]

~~Actually I managed to solve my issue by just keep Supabase running on http and disabling ad blocker (it was actually adblocker who was disabling requests to http://127.0.0.1:54321/rest/v1/... when app was being open on https://<my_hostname>.local:<port> but it would still be nice to be able to pass custom certs to Supabase~~

Actually I can't do that because when accessing from the phone I can't make Supabase requests to http://127.0.0.1:54321. It needs to be http://<my_hostname>.local:54321/rest/v1/... and then browser blocks my request because of mixed content. The only why to do it is to then allow mixed content which is not ideal because it is not even possible on iOS. So ideally we should be able to point Supabase to use our cert and then I could do https://<my_hostname>.local:54321/rest/v1/...

[tripflex]

Yeah i'm interested in this too, is there really no way to use our own SSL certificates for the API when using Supabase CLI?

[jbojcic1]

hey @sweatybridge I saw that you implemented this so I tried it but I have one issue. My supabase github integration is failing with this error failed to read TLS cert: open supabase/env(SELF_SIGNED_CERT): no such file or directory

do you know why? how can I make it read env var? also why is it even trying to use that for preview envs? I thought that's just for local tls

my config in toml for tls looks like this:

[api.tls]
# Enable HTTPS endpoints locally using a self-signed certificate.
enabled = true
# Paths to self-signed certificate pair.
cert_path = "env(SELF_SIGNED_CERT)"
key_path = "env(SELF_SIGNED_CERT_KEY)"

[sweatybridge]

We treat preview branch and local the same way because they are both development environments. In order to make sure whatever that's working locally is also working on a remote branch, we use the same config.toml file.

That said, it's definitely a bug on our side when handling tls cert. I will look into it next week.

[jbojcic1]

We treat preview branch and local the same way because they are both development environments. In order to make sure whatever that's working locally is also working on a remote branch, we use the same config.toml file.

That said, it's definitely a bug on our side when handling tls cert. I will look into it next week.

But am I right that tls config should be ignored for preview branches because they always have tls enabled and are using real (not self signed) certs?

[lecramr]

Hey, currently also trying to use this feature, when I try to start supabase again, after adding the tls = enabled and the certs I get the following error:

❯ supabase start
WARN: no SMS provider is enabled. Disabling phone login
WARNING: You are running different service versions locally than your linked project:
supabase/gotrue:v2.156.0 => v2.180.0
Run supabase link to update them.
Starting database from backup...
Starting containers...
Waiting for health checks...
supabase_rest_pontis container logs:
15/Oct/2025:11:26:57 +0000: Starting PostgREST 12.0.2 (a4e00ff)...
15/Oct/2025:11:26:57 +0000: Attempting to connect to the database...
15/Oct/2025:11:26:57 +0000: Connection successful
15/Oct/2025:11:26:57 +0000: Admin server listening on port 3001
15/Oct/2025:11:26:57 +0000: Listening on port 3000
15/Oct/2025:11:26:57 +0000: Listening for notifications on the pgrst channel
15/Oct/2025:11:26:57 +0000: Config reloaded
15/Oct/2025:11:26:57 +0000: Schema cache loaded
Stopping containers...
failed to execute http request: Head "https://127.0.0.1:54321/rest-admin/v1/ready": tls: failed to verify certificate: x509: cannot validate certificate for 127.0.0.1 because it doesn't contain any IP SANs
Try rerunning the command with --debug to troubleshoot the error.

[jbojcic1]

We treat preview branch and local the same way because they are both development environments. In order to make sure whatever that's working locally is also working on a remote branch, we use the same config.toml file.

That said, it's definitely a bug on our side when handling tls cert. I will look into it next week.

@sweatybridge did you have time to check this? Should I create a separate issue?

[sweatybridge]

@lecramr could you try to generate local certs using the example command here https://github.com/supabase/cli/blob/develop/internal/status/status.go#L158-L160

I suspect you are missing subjectAltName in your local certs.

But am I right that tls config should be ignored for preview branches because they always have tls enabled and are using real (not self signed) certs?

@jbojcic1 yes, you are right that tls config won't be applied to preview branches.

The failed to read TLS cert error is due to env(SELF_SIGNED_CERT) not being resolved to an env var. A few options

1. add .env file to your git repo and set them as empty strings

SELF_SIGNED_CERT=
SELF_SIGNED_CERT_KEY=

2. use actual file paths in config.toml and commit your local certs in git repo

[jbojcic1]

@jbojcic1 yes, you are right that tls config won't be applied to preview branches.

The failed to read TLS cert error is due to env(SELF_SIGNED_CERT) not being resolved to an env var. A few options

1. add .env file to your git repo and set them as empty strings

SELF_SIGNED_CERT= SELF_SIGNED_CERT_KEY= 2. use actual file paths in config.toml and commit your local certs in git repo

@sweatybridge none of the options is ideal. Can't do num 2 because our local certs are autogenerated and are different for every developer. Will try num 1 but will make other things more complex (.env file is not committed atm).

Do you think cli will ever be updated to completely ignore the non existing path for this (since it's not used anyway) or that is not something you will be doing anytime soon?

[sweatybridge]

Will try num 1 but will make other things more complex (.env file is not committed atm).

We support supabase/.env too if that gives you a clearer separation from your project's .env file.

There's also .env.local that you can use to override values in .env in case you choose to commit it to git repo.

Do you think cli will ever be updated to completely ignore the non existing path for this

It will be quite complex to change on cli side because we currently use the same config validation logic on branching. We'd have to come up with a more general way to distinguish config values for branches vs local and that will likely take some time.

[jbojcic1]

@sweatybridge I tried this approach but I still get the same error:

The error can be seen here.

I did as you suggested and committed supabase/.env file with content:

SELF_SIGNED_CERT_PATH=
SELF_SIGNED_CERT_KEY_PATH=

You can see the code where I implemented your suggestion in this commit. Full PR here.

[jbojcic1]

I guess I need to commit some cert after all and then use that in supabase/.env instead of empty path?

[sweatybridge]

I will check this in an hour or so and let you know. Sorry that we have to go back and forth on this.

[sweatybridge]

@jbojcic1 I've updated branching to ignore tls config completely. Could you give it another try?

[jbojcic1]

@jbojcic1 I've updated branching to ignore tls config completely. Could you give it another try?

You mean I should be able to not even specify .env file now?

[sweatybridge]

You mean I should be able to not even specify .env file now?

Yup that's right.

[jbojcic1]

You mean I should be able to not even specify .env file now?

Yup that's right.

@sweatybridge I need to upgrade cli to latest prerelease, right?

[sweatybridge]

@jbojcic1 I mean you can push a commit to your PR and branching pipeline should be able to run without additional .env or certs. Local development is pretty much the same so you don't need to upgrade the cli.

[jbojcic1]

@sweatybridge this worked. Thx for the help.