Deploys a MULTI-CONTAINER app — a repo that ships a docker-compose.yml / compose.yaml (app + its own db/redis/worker containers) — onto ONE VM via podman-compose, and exposes ONE service at https://<name>-<id>.redu.cloud. Use this instead of deploy_app when the repo is a compose stack rather than a single Dockerfile. SAME prereqs + source modes as deploy_app: run check_deploy_prerequisites (network_id + keypair_name), then GIT (`repo`, +git_token for private) or UPLOAD (prepare_upload → source_token). PORT: pass the HOST port the exposed service publishes (the LEFT side of its `ports:` mapping) — redu probes + proxies that exact port; pass `service` to name which service it is (plan_deploy detects both). DB: 'compose' (default) uses the stack's own db service (self-contained); 'single_vm'/'managed' provision a Postgres/MySQL and APPEND its conn env (DATABASE_URL/PG*/MYSQL_*) to the project .env — your compose must REFERENCE those vars to use it (we never rewrite your compose file). Build+provision can take 4-40 min (it pulls/builds every service — heavy ClickHouse/Kafka stacks are slow); poll get_deployment until status='ready', and on failure read build_log (it captures podman-compose logs). TIPS: (1) prefer the project's PREBUILT published images — swap any `build:` block for the published `image:` tag (building from source on the VM is less reliable). (2) redu injects APP_URL/PUBLIC_URL (= the app's public URL) into the env — map the app's own URL/cookie-domain var (SERVER_URL/NEXTAUTH_URL/…) to ${PUBLIC_URL}. (3) multi-surface apps (dashboard + API on separate ports) → pass `expose:[{port,service},…]`, each gets its own URL. ALWAYS run plan_deploy first and confirm the plan + cost with the user.
Connector