Схема розміщення: де що працює і на чиєму акаунті

Cloudflare, Vercel і Supabase - акаунти Green Co; домен порталу веде на Worker
Тунель до стенда теж заведено в Cloudflare Green Co; на сервері 1С стоїть лише служба cloudflared
Машина-виконавець і тестовий стенд 1С - на боці розробника порталу, не в акаунтах Green Co
Робочий сервер 1С замовника ще не підключено

Усе, що йде на домен, приймає Worker: сайт і шлюз фото обробляє сам, решту без змін передає на Vercel
Supabase Cron раз на 15 хв викликає /api/sync/run; у vercel.json є ще добовий крон 0 3 * * * на той самий маршрут
З Vercel до 1С - лише тунелем: портал шле Basic для OData і ключ X-Portal-Key; ключ перевіряє вебсервер
Скрипти ходять у 1С приватною мережею (OData), а на портал - через домен: /api/sync/inbound, /api/sync/orders-outbox, шлюз фото
Розклад скриптів: замовлення - щохвилини, борг - не частіше ніж раз на 10 хв, фото - щодня о 03:15

Vercel: сторінки /catalog, /client, /manager і маршрути /api/orders, /api/sync/*, /api/product-image
Supabase: Postgres (репліка products, prices, stock, customers; orders_snapshot; черга orders_outbox) і вхід за email
R2: дві WebP-копії кожного фото і маніфест; читання і запис - різними ключами через шлюз
Стенд: копія тестової бази замовника з розширенням прт_Портал; одна публікація віддає OData і /hs/portal

У роботі: клієнт сервісу /hs/portal і перемикачі ORDERS_CREATE_VIA, ORDERS_CHANGE_VIA (типово odata)
Адресу і токен сервісу отримає кожен виконавець: Vercel і скрипт замовлень; у черзі з'явиться стан rejected
У main цього ще немає: до 1С портал ходить лише через OData
Наступний крок - робочий сервер замовника. На стенді відпрацьовано тунель із ключем, інші способи доступу не перевірялися; публікації OData і сервісу на робочому сервері плануються окремі