feat: allow customization of the supabase root directory name and config paths

Is your feature request related to a problem? Please describe.
I have a monorepo that has a very specific naming structure with /apps and /libs folders. The option for --workdir is great when initializing a new project, however I would love to specify the name of the root directory alongside this.

Describe the solution you'd like
Having a cli flag for --rootname <folder name> would be great.

Describe alternatives you've considered
The alternative is to place a parent folder with the desired name before initializing a project. Eg: apps/testproject/supabase.
Something like this is required for multiple projects to exist within a monorepo.

Additional context
This appears to currently be hardcoded in internal/utils/misc.go.
I am unsure whether other considerations are needed such as an indicator for what is a supabase directory or not. Maybe the CLI can automatically detect this based off --workdir or the contents of the cwd.

Do you mean to customize like apps/testproject/custom-supabase? That wouldn't be possible because a lot of our platform's GitHub integrations depend on a directory named supabase.

If you mean apps/testproject/supabase, I think it's already supported with supabase init --workdir apps/testproject flag.

Yes I mean apps/testpropject/custom-supabase - this would be great. Maybe this can be accomplished by having the directory name specified in the config.toml instead of assumed to be supabase always?

project_id already exists in the config.toml, I assume to combat some of these issues already. Why not allow root_name or something similar as well?

config.toml lives inside supabase directory though. How would you suggest we find the right config.toml file if we support custom-supabase directory?

@sweatybridge

@sweatybridge I'm also interested in the possibility to place Supabase directories anywhere I want in my project.
Next.JS docs encourage a structure where everything is in the src or app folder, and the root directory is only used for config files.
I can imagine a supabase.config.toml, or supabase.config.ts, or a .supabase directory in the root (personally prefer the first solution) where you would provide the paths of supabase stuff!

I see, so perhaps a --config <path-to-toml> flag that can be passed to CLI to override the default location of supabase/config.toml.

Within config.toml, users can declare path overrides for other directories relative to the location of config.toml. For eg.

workdir = '..'

[migrations]
path = './migrations/*.sql'

[seed]
path = './seed.sql'

[functions.slug]
path = '../src/index.ts'

I see, so perhaps a --config <path-to-toml> flag that can be passed to CLI to override the default location of supabase/config.toml.

Within config.toml, users can declare path overrides for other directories relative to the location of config.toml. For eg.
workdir = '..'

[migrations]
path = './migrations/*.sql'

[seed]
path = './seed.sql'

[functions.slug]
path = '../src/index.ts'

This could indeed be handy. I using a monorepo for multiple identical apps with the same supabase setup and would like to have separate config (with different project_id) for each project, but use the same migrations/seed etc. This would probably do the job.

I see, so perhaps a --config flag that can be passed to CLI to override the default location of supabase/config.toml.

This would also be handy to have separate containers and volumes for running e2e tests without touching your development instances.

I would like to have a feature in which I can simply reset my local database once with my declarative schemas, e.g. instead of diffing it, just apply all declared schemas (sql files) as migrations once.

I think that would be a handy option keep sql code of early projects organized.

Something like db reset --use-schemas or db apply or db apply schemas.

what about changing this dir's name to .supabase as the dir name?
git cursor and pycharm use it

This is unexpected, I have a monorepo as well and the need for multiple supabase dbs in the same project, I was wondering why I'm seeing all these errors in my failing CI flow, after renaming supabase/ to customer-db/.

Really expected this to be working, how else can I have multiple db's in one project?

@madsem

@madsem what i ended up doing is creating a git project for each db. might be a little hassle to migrate, but it was worth it in my case.

@madsem what i ended up doing is creating a git project for each db. might be a little hassle to migrate, but it was worth it in my case.

That could def be an option, sadly not for our use case. Currently thinking of just going the route of least resistance, and just nest one more level:

customer-db/
├── README.md
└── supabase/
    ├── config.toml
    ├── migrations/
    └── seed.sql

analytics/
├── README.md
└── supabase/
    ├── config.toml
    └── migrations/

etc.

@madsem

@madsem 100%, would've done the same if separation was not sensible for us
if you use supabase CLI it should also recognize that you have 2 projects, you can set both locally \w docker, just make sure you use different ports so both work back to back locally
good luck!

@sweatybridge

@sweatybridge can we please get this added? you seem to have already agreed to adding this functionality and there's an open PR that implements it.

could you take a look and give an update? thanks in advance!

@sweatybridge

@sweatybridge I'd like to take this if the design is still the one you sketched here.

First slice, matching your comments:

add --config <path> so the CLI isn't hardcoded to supabase/config.toml
derive workdir from that config path (the gap you called out on Add Custom Config File Support #3092)
allow path overrides in the toml relative to the config file (migrations, seed, functions)
keep today's supabase/ layout as the default

Could this get open-for-contribution so a PR won't be auto-closed? Happy to wait if the scope should be smaller.

Navigation Menu

Repository navigation

feat: allow customization of the supabase root directory name and config paths #2139

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

feat: allow customization of the supabase root directory name and config paths #2139

Description

Activity

sweatybridge commented on Apr 10, 2024

Bowbee commented on Apr 10, 2024

sweatybridge commented on Apr 10, 2024

tomx-sh commented on Apr 10, 2024

sweatybridge commented on Apr 15, 2024

baffioso commented on Aug 1, 2024

djhi commented on Oct 16, 2024

Donnerstagnacht commented on Apr 26, 2025

IdanDavidAviv commented on May 24, 2025

madsem commented on Jul 5, 2025

IdanDavidAviv commented on Jul 5, 2025

madsem commented on Jul 5, 2025

IdanDavidAviv commented on Jul 5, 2025

imtreydp commented on Jun 7, 2026

leen-neel commented on Aug 24, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions