Support Integer in the config.toml via the "env()" function

[jones1008]

I first brought this up in the discussions but I think here is a more fitting space

Is your feature request related to a problem? Please describe. In my config.toml I tried to setup my ports to reference environment variables as follows:

[api]
port = "env(SUPABASE_API_PORT)"

SUPABASE_API_PORT=1234

When trying to run supabase start now it throws me the following error:

Error: cannot read config in /home/jfl/projects/poodle/poodle-frontend: toml: line 7 (last key "api.port"): incompatible types: TOML value has type string; destination has type integer
Have you set up the project with supabase init?

Describe the solution you'd like It seems the env() function is only supported for strings inside the config.toml. It would be nice to also be able to configure your ports (type Integer) via environment variables

We would need a solution that is .toml syntax compliant and allows for integer values (and potentially other types). I don't know the implementation of how supabase-cli replaces the env() with its variables at runtime (I don't know Go), but maybe we could make something that works like follows:

[api]
port = "env(SUPABASE_API_PORT) as integer"

The supabase-cli then could detect that it says env() as integeer and remove the whole string (including ") so we would have only the integer at runtime but still have a valid .toml syntax.

Describe alternatives you've considered I tried to omit the " around the env() but that is a .toml syntax error:

[api]
port = env(SUPABASE_API_PORT)

Error message:

$ supabase start
Error: cannot read config in /home/jfl/projects/poodle/poodle-frontend: toml: line 7 (last key "api.port"): expected value but found "env" instead

Additional context

[thenbe]

Unable to set the port through an environment variable is painful.

The current workaround for this issue is to manually duplicate these values (e.g. $SUPABASE_API_PORT now needs to be explicitly declared both in your .env and in config.toml.

This is an issue because it leaves the config.toml vulnerable to going out-of-sync. (e.g. a team member updates the value of SUPABASE_API_PORT in .env but does not update it in config.toml).

Cause

config.toml already knows how to interpolate from environment variables. But it fails when the config key expects a integer. If the config key expects a string, everything works fine.

# config.toml

# this works (because `s3_region` expects value of type string)
s3_region = "env(S3_REGION)"

# this does not work (because `port` expects value of type integer)
port = "env(SUPABASE_API_PORT)"

toml: line 7 (last key "api.port"): incompatible types: TOML value has type string; destination has type integer

Proposal

For config keys that expect type integer, we should attempt to coerce the input into an integer before failing.

It's intuitive; this is the behavior users are going to naturally expect. And I can't think of any downsides to doing this.

[rileytaylor]

Being able to do this with boolean values as well would also solve issues in CI environments as discussed here: https://github.com/supabase/edge-runtime/issues/235

Being able to use config.toml as a driver for a 12-factor style env approach for the local environment and deploy workflows for 1+ hosted environments would greatly simplify the environment workflow recommended in the docs too: https://supabase.com/docs/guides/cli/managing-environments