>> Но в целом понял: только контейнер с сайтом поднимается сам, а для всего остального нужен комплекс контейнеров.
Это надо смотреть индивидуально. Смотри, когда мы запускаем
API_ENDPOINT=https://pivkarta.ru/api/ docker-compose -f docker-compose.yml -f docker-compose.dev.yml up --build pivkarta.ru-2
то API запросы будут лететь на https://pivkarta.ru/api/, то есть да, в таком случае ему нужно только чтобы сайт https://pivkarta.ru был доступен.

Альтернативно можно API_ENDPOINT=https://pivkarta.ru/api/ прописать в .env и запускать как обычно
docker-compose -f docker-compose.yml -f docker-compose.dev.yml up --build pivkarta.ru-2

Просто в .env пишутся переменные окружения по умолчанию, но их можно переопределить, прописав в начале выполнения команды.

Так вот, если у тебя будет прописано типа API_ENDPOINT=http://api:4000, то тогда уже запросы будут лететь на этот сервер, а не внешний pivkarta.ru, то есть у тебя должен быть запущен контейнер api. А api куда запросы шлет? На prisma. А prisma что для себя требует? Откуда данные берет? mysql. Вот тебе и цепочка. Как минимум эти контейнеры ты должен запустить для работы.

А еще в mysql заглянуть надо? - pma запускаешь.

Но в дев-режиме-то у нас порты открыты, а в прод - нет. То есть просто так не достучишься. Значит что нам нужно? Прокси-сервер. А это уже proxy. Помнишь в начале инструкции писал? cp caddy/Caddyfile.sample caddy/Caddyfile

Вот посмотри этот сампл. Пример

0.0.0.0:2016 { tls off gzip # log / stdout "API: {upstream} {combined} UPSTREAM: {upstream} REWRITE: {rewrite_uri} TOKEN: {>X-App-Token} COOKIE:{~AppSession}\n" proxy / api:4000 { transparent websocket } }
Ничего не узнаешь?

То есть если прокси запустишь, http://localhost:2016 - это будет API. http://localhost:2015 - фронт. http://localhost:2017 - PhpMyAdmin.

Вот, и уже ты локальный хостинг-провайдер )))