feat: allow network to be defined

[samlown]

What kind of change does this PR introduce?

Simple change to allow a custom docker network name to be used instead of the default.

What is the current behavior?

Default and only available network is supabase_network_project_id (where project_id is that of the current project).

What is the new behavior?

If the configuration toml defines this at the top-level:

network = my-custom-network

The network called my-custom-network will be used instead of the default.

Additional context

This is useful for running supabase inside an existing local development network so that other docker images can access supabase resources without going through the host. Given the simple names of supabase services, like db, auth, rest etc. there is a chance of name collisions. #1510 helps reduce complications with longer aliases.

[coveralls]

Pull Request Test Coverage Report for Build 6539692078

• 3 of 3 (100.0%) changed or added relevant lines in 1 file are covered.
• 5 unchanged lines in 1 file lost coverage.
• Overall coverage increased (+0.01%) to 57.132%

---

Files with Coverage Reduction	New Missed Lines	%
internal/gen/keys/keys.go	5	12.31%

Totals
Change from base Build 6530476829:	0.01%
Covered Lines:	5207
Relevant Lines:	9114

---

💛 - Coveralls

[sweatybridge]

This is useful for running supabase inside an existing local development network so that other docker images can access supabase resources without going through the host.

If supabase start errors due to unhealthy container, the current implementation will try to delete the network by id. This means any custom network may be deleted and recreated by cli if there are no resources using it. The recreated network will likely have different properties, like additional labels. Would this be a concern for you?

If so, I think a more desirable behaviour might be to leave the existing custom network alone. This can be implemented by pruning the network only if it matches a filter by label.

[samlown]

Thanks @sweatybridge! Normally docker wouldn't let you delete a network that is in active use, which is our case when using docker compose down, it'll just raise an error which is currently ignored as per the link you posted. Even if deleted, running docker compose up again will just re-create it from scratch.

In our use-case, this wouldn't be an issue, but I can see the potential for problems. Filtering by label for networks that were created by supabase could be a reasonable solution.

[sweatybridge]

I thought about this more and find that an extra flag like supabase start --use-network <id> might be more suitable here. Reason is network id doesn't seem to be a project level config. This concept doesn't apply to remote project, it may change between different local dev machines, and doesn't need to be committed to git.

I would be happy to add the start flag if you are ok with it too.

[sweatybridge]

closing due to staleness