Compute

Compute — рантайм для серверных приложений. В отличие от статических деплоев (файлы на CDN) и ONREZA Functions (короткие event-handlers без своего сервера), Compute запускает полноценный серверный процесс с файловой системой, WebSocket, native modules и доступом к платформенным API.

SSR-фреймворки (Next.js, Remix, Astro SSR) — это тоже Compute: серверный рендеринг выполняется в полноценном Bun-процессе.

Когда использовать Compute

Задача	Подходит?
Next.js SSR / App Router	Да
Remix SSR	Да
Express / Fastify / Hono API	Да
Кастомный Bun HTTP-сервер	Да
WebSocket сервер	Да
Статический сайт (Vite, CRA)	Нет — используйте STATIC
Лёгкие event-handlers (auth, redirects, webhooks)	Нет — используйте ONREZA Functions

Быстрый старт

Next.js (автоматически)

Next.js SSR определяется автоматически. Настройка не требуется — standalone output и process.env.PORT обрабатываются платформой.

Кастомный сервер

Минимальный пример для Express / Bun:

server.ts

import express from "express";

const app = express();
const PORT = parseInt(process.env.PORT || "3000");

app.get("/", (req, res) => {
  res.json({ hello: "world" });
});

app.listen(PORT, "0.0.0.0", () => {
  console.log(`Server running on port ${PORT}`);
});

Конфигурация порта

Обязательно

Ваше приложение должно слушать на порту из process.env.PORT. Платформа назначает порт динамически и проверяет доступность сервера на этом порту. Захардкоженный 3000 или 8080 не сработает.

// ✅ Правильно — читает порт из окружения
const PORT = parseInt(process.env.PORT || "3000");
app.listen(PORT, "0.0.0.0");

// ❌ Неправильно — захардкоженный порт
app.listen(3000);

// ❌ Неправильно — слушает только на localhost
app.listen(PORT, "127.0.0.1");

Важно: сервер должен слушать на 0.0.0.0 (все интерфейсы), не на 127.0.0.1. Платформа проверяет доступность извне сетевого пространства процесса.

Фреймворки и PORT

Фреймворк	Поддержка process.env.PORT
Next.js standalone	Автоматически
Remix	Автоматически
Express	Требуется ручная настройка
Fastify	Требуется ручная настройка
Hono	Требуется ручная настройка
Bun.serve	Требуется ручная настройка

Scale-to-zero

Compute-процессы автоматически масштабируются до нуля при отсутствии трафика:

1. Активный — обрабатывает запросы
2. Заморожен — после 15 секунд без запросов процесс приостанавливается (SIGSTOP). Память выгружается. Возобновление за 1-50ms при следующем запросе.
3. Остановлен — после plan-dependent времени в замороженном состоянии процесс полностью завершается. По умолчанию: Hobby — 1 минута, Pro — 2 минуты, Enterprise — 5 минут. Следующий запрос запустит cold start.

Заметка

Замораживание и возобновление прозрачны для пользователя — запрос просто ждёт 1-50ms дольше. Cold start после полной остановки занимает 1-30 секунд в зависимости от размера приложения.

Ресурсы и ограничения

Параметр	Значение по умолчанию	Настраивается
Память	256 MB	Да
CPU	Shared	Да
PIDs	512	—
Таймаут запуска	30 секунд	—
Файловая система	Read-only + overlay	—
Размер /tmp	256 MB	—
Размер записываемого слоя	512 MB	—
Исходящий трафик	25 Mbit/s	—

Настройки памяти и CPU задаются в Settings → Compute или через manifest.

Память для Next.js

Значение по умолчанию (256 MB) может быть недостаточно для Next.js standalone. Если приложение падает с OOM при запуске, увеличьте память до 512 MB и выше.

Приоритет CPU

CPU на сервере — общий ресурс, разделяемый между всеми запущенными приложениями. Каждому процессу назначен лимит CPU (максимум, который он может использовать) и приоритет (доля при конкуренции).

Лимит — жёсткий потолок. Если вы задали лимит CPU в настройках, приложение никогда не превысит его — даже если сервер временно свободен.

Приоритет работает только при нагрузке. Когда несколько процессов одновременно нуждаются в CPU, ONREZA распределяет ресурс пропорционально приоритету. Если конкуренции нет, приоритет не влияет — все получают сколько нужно.

Приоритет зависит от плана и типа деплоя:

План + тип деплоя	Приоритет
Hobby, preview	1×
PRO, preview	5×
Hobby, production	10×
Enterprise, preview	20×
PRO, production	50×
Enterprise, production	100×

На практике это означает, что production-деплой на PRO получит в 50 раз больше процессорного времени, чем preview на Hobby, если оба окажутся под нагрузкой одновременно.

Совет

Production-деплой всегда имеет приоритет выше, чем preview следующего по уровню плана. Ваш рабочий сайт на плане Hobby получит CPU раньше, чем тестовый preview на плане PRO.

Файловая система

Корневая файловая система (/output) — read-only с overlay. Ваше приложение может записывать файлы, но записи хранятся во временном слое:

• Записи теряются при scale-to-zero (полная остановка процесса)
• Записи сохраняются при заморозке/разморозке (SIGSTOP/SIGCONT)
• Максимальный размер записываемого слоя — 512 MB

Для временных файлов используйте /tmp (256 MB).

Лимит исходящего трафика

Каждый sandbox ограничен скоростью исходящего трафика в 25 Mbit/s. Это защитный механизм — предотвращает злоупотребления и обеспечивает стабильность соседних процессов.

Сетевые ограничения

Compute-процессы имеют полный доступ к интернету (HTTP, базы данных, внешние API) с ограничениями на отправку email:

Возможность	Hobby	PRO
HTTP/HTTPS запросы	Да	Да
Подключение к БД (PostgreSQL, MySQL, Redis, MongoDB)	Да	Да
WebSocket соединения	Да	Да
Отправка email (SMTP, порты 465/587/2525)	Нет	Да (до 100 соединений/мин)

SMTP на Hobby плане

Порты SMTP (465, 587, 2525) заблокированы на плане Hobby для предотвращения злоупотреблений. Если вашему приложению нужно отправлять email (транзакционные письма через SendGrid, Postmark, AWS SES и т.д.), обновите план до PRO.

Порт 25 (raw SMTP) заблокирован на всех планах — это индустриальный стандарт. Используйте порты 465 или 587 через email-провайдера.

Заметка

На PRO плане отправка email ограничена 100 соединениями в минуту на процесс. Для большинства приложений с транзакционными письмами этого достаточно с запасом (email-библиотеки используют пул соединений).

Заблокированные сетевые порты

Compute работает в инфраструктуре Selectel и дополнительно применяет платформенный denylist для портов, которые Selectel блокирует на границе сети из-за риска abuse, amplification-атак или небезопасных legacy-протоколов.

Порты	Протокол	Назначение
17	TCP/UDP	QOTD
111	TCP/UDP	ONC RPC / SunRPC
135	TCP/UDP	Microsoft EPMAP
137, 138, 139	TCP/UDP	NetBIOS
389	TCP/UDP	LDAP
427	TCP/UDP	SLP
445	TCP/UDP	SMB
520	UDP	RIP
1900	UDP	SSDP
3702	UDP	WS-Discovery
11211	TCP/UDP	Memcached

SMTP-политика ONREZA остается отдельной:

• 25/TCP заблокирован на всех планах.
• 465/587/2525/TCP заблокированы на Hobby.
• На PRO 465/587/2525/TCP разрешены, но ограничены по частоте.

Environment Variables

Переменные окружения задаются в Settings → Environment Variables и автоматически передаются в процесс:

// Стандартный доступ
const dbUrl = process.env.DATABASE_URL;

Системные переменные, которые платформа устанавливает автоматически:

Переменная	Описание
PORT	Порт, на котором должен слушать сервер
NODE_ENV	production
HOSTNAME	0.0.0.0
HOME	/tmp
TMPDIR	/tmp
XDG_CACHE_HOME	/tmp/.cache
PATH	Стандартные системные пути
USER	onreza
LANG	C.UTF-8

Платформенные API

В Compute-приложениях используйте стандартные runtime API и платформенные переменные окружения. Для edge/auth state используйте ONREZA Functions bindings, а оптимизацию изображений вызывайте через URL endpoint:

• KV Store — key-value хранилище для ONREZA Functions
• Image Optimization — оптимизация изображений
• Runtime API — текущий публичный runtime contract

Перезапуск при сбое

Если Compute-процесс падает (crash, OOM, необработанное исключение), ONREZA автоматически перезапускает его:

• До 10 перезапусков в окне 5 минут
• Задержка между попытками увеличивается экспоненциально: 1с, 2с, 4с, 8с, 16с, 30с (максимум)
• После 10 неудачных перезапусков деплой помечается как Failed

Во время перезапуска входящие запросы получают HTTP 503 с заголовком Retry-After, что позволяет клиентам повторить запрос позже.

Совет

Если процесс стабильно работает более 5 минут, счётчик перезапусков сбрасывается. Редкие случайные крэши не приведут к постоянному Failed.

Автоматическое управление памятью

ONREZA непрерывно мониторит потребление памяти каждого Compute-процесса и автоматически реагирует на проблемы — вплоть до бесшовной перезагрузки при утечках.

Автоматическое масштабирование

Если ваше приложение стабильно использует более 80% выделенной памяти в течение минуты, платформа автоматически увеличивает лимит (×1.5), не прерывая работу процесса. Масштабирование происходит мгновенно и прозрачно.

Масштабирование ограничено максимальным лимитом памяти вашего плана. Фактическое потребление Compute считается в CU и покрывается usage credit; usage сверх credit допускается только в пределах вашего extra usage budget.

Обнаружение утечек памяти

Если память продолжает расти линейно более 2.5 минут (pattern: потребление растёт, а не стабилизируется), платформа определяет это как утечку памяти:

1. Продолжает увеличивать лимит, давая приложению время работать
2. Отправляет уведомление о предполагаемой утечке
3. Если утечка достигает максимального лимита памяти — запускает бесшовную перезагрузку

Бесшовная перезагрузка (blue-green restart)

Когда утечка памяти достигает максимального лимита, ONREZA не убивает процесс, а выполняет zero-downtime замену:

1. Запускается свежий экземпляр приложения с начальным лимитом памяти
2. Новый экземпляр проходит health check
3. Трафик мгновенно переключается на новый экземпляр
4. Старый (утекающий) процесс корректно завершается

Совет

Для пользователей это полностью прозрачно — запросы продолжают обрабатываться без перерыва. Приложение с утечкой памяти может работать неограниченно долго, пока вы не найдёте и не исправите причину.

Стадии реакции

Состояние	Что происходит	Действие платформы
Норма	Потребление < 80% лимита	Мониторинг
Давление	P80 > 80% более 60 секунд	Автоматическое увеличение лимита ×1.5
Утечка	Линейный рост 2.5+ минут	Уведомление + продолжение масштабирования
Максимальный лимит	Утечка достигла максимума	Бесшовная перезагрузка (blue-green)

Заметка

Если бесшовная перезагрузка не удалась (например, приложение не может запуститься), процесс продолжает работать на максимальном лимите до OOM kill ядром, после чего применяется обычный перезапуск при сбое.

Troubleshooting

“Startup timeout”

Приложение не запустилось за 30 секунд.

Частые причины:

1. Неправильный порт — используйте process.env.PORT, не захардкоженное значение
2. Dev-сервер в production — vite dev, next dev, webpack-dev-server не работают в production. Соберите приложение и запустите production-сервер
3. Слушает на localhost — используйте 0.0.0.0, не 127.0.0.1
4. Тяжёлая инициализация — если приложению нужно больше 30 секунд на старт, оптимизируйте инициализацию

Совет

Платформа автоматически определяет, если ваше приложение слушает на неправильном порту, и включает подсказку в сообщение об ошибке.

“Connection refused”

Сервер запустился, но не отвечает на запросы.

1. Убедитесь что сервер слушает на 0.0.0.0, не на 127.0.0.1
2. Проверьте что process.env.PORT используется

“Out of memory”

Процесс превысил лимит памяти.

1. Увеличьте лимит в Settings → Compute
2. Проверьте утечки памяти в приложении
3. Для Next.js: standalone build оптимальнее, чем next start

См. также

• Фреймворки — настройки для каждого фреймворка
• Build Output Manifest — конфигурация COMPUTE слоёв
• ONREZA Functions — короткие event-handlers без своего сервера
• Runtime API — поддержанные platform bindings