Биллинг: базовый уровень
Эта страница для случая «хочу быстро понять, за что именно плачу».
Зачем нужна модель из нескольких метрик
Заголовок раздела «Зачем нужна модель из нескольких метрик»Если считать только количество запросов, лёгкий и тяжёлый запросы стоят одинаково. Это несправедливо.
Поэтому биллинг смотрит на фактическую нагрузку: сколько вычислительных ресурсов занято, сколько данных доставлено пользователю и как долго хранятся файлы. Billable-метрики тарифицируются с первой единицы и затем покрываются usage credit плана.
ONREZA Compute — серверные приложения
Заголовок раздела «ONREZA Compute — серверные приложения»Полноценный runtime для ресурсоёмких задач: SSR, API, бэкенд-операции.
Что считается
Заголовок раздела «Что считается»- Вычисления ONREZA Compute (
process_compute_cu_seconds) — единая CU-метрика для серверного runtime - В расчёт входят фактическое CPU, фактическая память во времени и активное удержание процесса
- 1 CU соответствует 1 vCPU + 4 ГБ RAM. Низкая нагрузка с долгим удержанием процесса получает минимальный CU-floor, а CPU/RAM-heavy нагрузка считается по фактическому потреблению
Что не считается
Заголовок раздела «Что не считается»- Запросы, отклонённые до запуска пользовательского кода
- Полностью статическая выдача без выполнения Runtime
- Технические системные ретраи без пользовательского ответа
ONREZA Functions — короткие handlers
Заголовок раздела «ONREZA Functions — короткие handlers»ONREZA Functions подходят для небольших HTTP handlers, webhooks и middleware. В public beta они тарифицируются одним BFU-hour meter: платформа сводит длительность, память, idle host, transfer, invocations и cold starts в BFU-seconds, а счёт округляется блоками по 1 BFU-hour. Защитные лимиты плана ограничивают выполнение Functions.
Что считается
Заголовок раздела «Что считается»- Количество вызовов функции
- Длительность выполнения и удержание памяти
- Размер ответа, egress, timeout/error/cold-start counters
Статические сайты и CDN
Заголовок раздела «Статические сайты и CDN»Доставка статических файлов, хранение артефактов деплоя, оптимизация изображений.
Что считается
Заголовок раздела «Что считается»- Egress (
static_egress_gb) — объём данных, доставленных пользователю - Storage (
static_storage_gb_month) — хранение файлов деплоя - Image transforms (
static_image_transforms) — трансформации изображений (resize, конвертация формата) - Origin fetch (
static_origin_fetch_gb) — запросы к origin-серверу при cache miss
Что не считается
Заголовок раздела «Что не считается»- Внутренний service-to-service трафик платформы
- Кэш-хиты, не создающие origin egress
- Retry/rehydration без пользовательского ответа
Управляемый PostgreSQL
Заголовок раздела «Управляемый PostgreSQL»Управляемый PostgreSQL с автомасштабированием, ветвлением баз данных и pay-as-you-go биллингом.
Что считается
Заголовок раздела «Что считается»- Вычисления (
compute_cu_seconds) — CU-weighted время работы сервера (cu_size × active_time). В счёте 3 600 CU-секунд образуют 1 CU-час; 1 час на 2 CU = 2 CU-часа - Storage (
storage_gb_month) — объём данных и WAL по времени в расчётном периоде (стоимость включает written_data) - Data transfer (
transfer_gb) — объём данных, переданных между приложением и базой - Базы данных (
database_months) — время активности БД за период - Ветки БД (
branch_months) — время активности веток за период
На текущих самообслуживаемых тарифах базы данных и ветки остаются в статистике использования с нулевой ставкой. В Enterprise индивидуальный договор может установить плату за время активности базы данных; ветки отдельно не тарифицируются. Их compute, storage и transfer учитываются обычными ресурсными метриками.
Что не считается
Заголовок раздела «Что не считается»- Время простоя (auto-suspend) — за suspended сервер compute не начисляется
- Внутренние операции платформы (репликация, бэкапы)
- Autoscale events (compute автоматически учитывает resize через CU-секунды)
Сборки и диагностические метрики
Заголовок раздела «Сборки и диагностические метрики»Часть метрик считается вне конкретного runtime-слоя:
build_minutes— billable время сборки проектовkv_storage_mb— диагностический показатель и защитный лимит объёма KV; отдельный line item не создаётся
Финальный счёт формируется по отдельным gross line items каждого слоя. Затем применяется included usage credit плана. Это делает расчёт прозрачным и проверяемым: всегда можно определить, какая метрика какого слоя дала основной вклад, какая часть покрыта credit и какая часть попала в extra usage.