Compute

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

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

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

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

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. Остановлен — после 2 минут в замороженном состоянии процесс полностью завершается. Следующий запрос запустит 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 и выше.

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

Корневая файловая система (/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-библиотеки используют пул соединений).

Environment Variables

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

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

// Или через Runtime SDK
import { env } from '@onreza/runtime/env';
const dbUrl = env.get("DATABASE_URL");

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

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

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

В Compute-приложениях доступны все платформенные API через SDK @onreza/runtime:

• KV Store — key-value хранилище
• D1 Database — SQL база данных
• Image Optimization — оптимизация изображений
• Runtime SDK — полная документация

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

Если 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), не прерывая работу процесса. Масштабирование происходит мгновенно и прозрачно.

Масштабирование ограничено hard cap — максимальным лимитом памяти вашего плана. Потребление сверх стартового лимита тарифицируется по метрике Memory GB-сек.

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

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

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

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

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

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

Совет

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

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

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

Заметка

Если бесшовная перезагрузка не удалась (например, приложение не может запуститься), процесс продолжает работать на hard cap до 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 слоёв
• Edge Runtime — V8 runtime для Edge Functions
• Runtime SDK — платформенные API