Интерфейс командной строки (CLI) Supabase теперь позволяет запускать несколько локальных проектов на одной машине, по одному на каждое рабочее дерево git (git worktree), и запускать их без использования Docker. Каждый агент разработки получает собственную базу данных для сброса, миграции и тестирования, в то время как остальные продолжают работать. Локальные проекты запускаются за считанные секунды и потребляют примерно в десять раз меньше памяти, а удаленная ветка, которая подхватывает работу при открытии pull request, работает почти в пять раз быстрее.
Поддержка нескольких проектов и нативная среда выполнения появились в CLI версии 2.119.0 за экспериментальным флагом. Ускоренные ветки сегодня доступны для каждого проекта.
Предположим, один агент занимается добавлением биллинга, а другой перерабатывает систему регистрации. Выделите каждому из них рабочее дерево git и выполните supabase start в обоих:
_10
git worktree add ../app-billing -b billing
_10
git worktree add ../app-signup -b signup
_10
_10
cd ../app-billing && supabase start
_10
cd ../app-signup && supabase start
Каждое рабочее дерево получает свои собственные экземпляры Postgres, Storage, Edge Functions и сервер MCP на портах, которые CLI выбирает и запоминает между перезапусками. Агент биллинга может выполнять supabase db reset в любое время, и тесты агента регистрации этого не заметят. Агенты считывают свои URL-адреса и ключи из supabase start --output-format json вместо использования значений по умолчанию, а благодаря декларативным схемам (Declarative Schemas 2.0) они редактируют файлы схем, позволяя CLI самостоятельно создавать миграции.
Больше не нужно вручную координировать идентификаторы проектов или порты, что было одним из самых востребованных изменений в CLI.
Команда supabase start запускает Postgres и оставляет все остальные службы в спящем режиме до первого запроса. Если ваша задача не затрагивает Storage, он не будет запущен. Спящие службы не потребляют процессорное время и память, останавливаются при простое и «просыпаются» при следующем запросе. Используйте флаг --eager, если хотите запустить всё сразу.
Девять простаивающих проектов теперь занимают столько же памяти, сколько раньше занимал один, что делает использование отдельного проекта для каждого рабочего дерева практичным решением даже на ноутбуке.
Агенты всё чаще работают в облачных «песочницах» (sandboxes) и CI-раннерах, где нет контейнерного движка. Нативная среда выполнения запускает все 13 служб Supabase как обычные процессы с теми же фиксированными версиями, что и в образах Docker, включая полный набор расширений Postgres, включая pgvector. Если Docker недоступен, CLI выберет этот режим за вас, или вы можете выбрать его самостоятельно:
_10
supabase start --runtime native
Он работает на Linux (amd64 и arm64, glibc 2.35 или новее) и macOS 14 или новее на процессорах Apple Silicon. Docker остается вариантом по умолчанию, если он присутствует, и по-прежнему лучше подходит для нескольких проектов на одном ноутбуке, так как каждый контейнер получает свою сеть и файловую систему. Воспринимайте нативный режим как «один проект на одну песочницу». Запуск Supabase локально без Docker также был давним запросом.
Когда открывается pull request, удаленная ветка предоставляет рецензентам URL-адрес для сборки, и эта ветка теперь поставляется с конфигурацией, унаследованной от исходного проекта. Аутентификация, хранилище, сетевые ограничения и развернутые Edge Functions переносятся при создании, а пакеты функций копируются параллельно, поэтому проект с 40 функциями запускается так же быстро, как и проект с двумя. Секреты остаются в безопасности, а производственные данные не копируются, если вы не решите создать ветку вместе с ними, поэтому ветку можно безопасно передать рецензенту сразу после готовности.
Обновитесь до CLI версии 2.119.0 или новее и включите экспериментальный движок. Для нового приложения:
_10
SUPABASE_EXPERIMENTAL_STACK=1 supabase init
Для существующего приложения добавьте stack = true в раздел [experimental] файла supabase/config.toml и выполните контрольный список по освобождению портов перед первым запуском. Закоммитьте файл, чтобы настройки применились ко всем рабочим деревьям.
Затем выберите настройку, соответствующую среде, в которой работают ваши агенты:
- Несколько агентов на вашем компьютере: используйте Docker или Podman, выделите каждому агенту свое рабочее дерево и запускайте supabase start в каждом из них. Руководство по нескольким локальным проектам охватывает вопросы просмотра списка, остановки и удаления проектов.
- Один проект в песочнице или CI-раннере: используйте supabase start --runtime native на поддерживаемой платформе. Контейнерный движок не требуется. Руководство по средам выполнения содержит информацию о настройке песочницы и списках разрешенных загрузок.
- Ветка в pull request: ничего включать не нужно. Ветки уже наследуют конфигурацию базового проекта, а руководство по ветвлению описывает все способы создания веток.
Экспериментальный движок хранит свои данные отдельно от существующего локального проекта, а его флаги и выходные данные могут измениться, поэтому ознакомьтесь с различиями и ограничениями перед переносом рабочего процесса.
Есть отзывы? Пожалуйста, поделитесь ими в репозитории CLI.
