Сколько RAM нужно для Astro

MAATRIX

Если вы уже развернули Astro-проект на дешёвом VPS с 1 ГБ RAM и получили JavaScript heap out of memory прямо на npm run build — вы не одни. Astro продают как «лёгкий» фреймворк с нулевым JS на клиенте, и это правда для отданной пользователю страницы. Но сама сборка — это Vite, Rollup, Sharp для картинок и, если у вас MDX или content collections, ещё и обработка Markdown — а это совсем не «лёгкий» процесс по памяти. Разберём отдельно, сколько RAM нужно на этапе сборки, сколько — на раздачу готовой статики, и сколько — если вы включили SSR.

Сколько RAM нужно на сборку (build)

Тут ключевую роль играет не сам Astro, а инструменты вокруг него.

Минимальный лендинг (5-10 страниц, без content collections, без тяжёлых изображений) собирается спокойно на 1 ГБ RAM, но с запасом лучше закладывать 2 ГБ — Rollup и Vite держат в памяти граф зависимостей, и на 1 ГБ без свопа сборка может упасть даже на небольшом проекте, если параллельно крутится ещё что-то (например, Nginx и SSH-сессия).

Блог или документация с content collections (десятки-сотни .md/.mdx файлов): Astro парсит каждый файл, строит схему через Zod (если используете defineCollection), генерирует статические страницы. На 100-300 страницах реалистично закладывать 2-4 ГБ. Обработка MDX компонентов (React/Vue/Svelte islands внутри контента) добавляет память — каждый UI-фреймворк, который вы подключили как интеграцию, тянет свой рендерер в сборку.

Сайт с оптимизацией изображений через astro:assets — отдельная история. Sharp (библиотека для обработки картинок под капотом) декодирует изображения в память по одному, но на большом количестве крупных исходников (десятки Full HD/4K фото) build может ощутимо просесть по памяти и по времени. Если у вас каталог товаров с сотнями фотографий — закладывайте 4-6 ГБ на сборку и по возможности сжимайте исходники заранее, до того как они попадут в astro:assets.

Практический ориентир (это именно ориентир, не измеренный бенчмарк — у вас будет отличаться в зависимости от количества интеграций, картинок и объёма контента):

Если сборка падает по памяти, а увеличить VPS сейчас не вариант, можно временно ограничить параллелизм Vite и дать Node больше heap:

# увеличить лимит памяти для Node при сборке
NODE_OPTIONS="--max-old-space-size=3072" npm run build

Это не увеличивает физическую RAM — если её реально не хватает, процесс всё равно упадёт, просто с другим сообщением об ошибке (OOM killer вместо heap error). Настоящее решение — либо больше RAM на сервере, либо своп-файл как страховка на время build, либо сборка не на проде, а в CI (GitHub Actions/GitLab CI), откуда на сервер попадает уже готовый dist/.

Сколько RAM нужно для раздачи готовой статики

Здесь хорошая новость: после npm run build вам для продакшена вообще не нужен Node.js в рантайме, если вы не используете SSR. Папка dist/ — это чистый HTML/CSS/JS, который раздаёт любой веб-сервер.

dist/
├── index.html
├── about/index.html
├── _astro/
│   ├── client.a1b2c3.js
│   └── styles.d4e5f6.css
└── favicon.svg

Nginx на 512 МБ RAM справляется с раздачей такой статики без проблем даже при заметном трафике — сам процесс Nginx под статику ест единицы-десятки мегабайт, основная память уходит на файловый кэш ОС, который Linux использует автоматически. Реалистичный минимум для чисто статического Astro-сайта в проде — 1 ГБ RAM (с запасом на ОС, SSH, логи, cron), но сама раздача не станет узким местом и на более скромной конфигурации.

Пример конфига Nginx под статику Astro:

server {
    listen 80;
    server_name example.com;
    root /var/www/example.com/dist;
    index index.html;

    # Astro сам хэширует имена файлов в _astro/, можно кэшировать агрессивно
    location /_astro/ {
        expires 1y;
        add_header Cache-Control "public, immutable";
    }

    location / {
        try_files $uri $uri/ $uri.html =404;
    }
}

Если сайт получает серьёзный трафик или вы хотите снять нагрузку с сервера ещё сильнее, статику Astro хорошо кладёт CDN — тогда вопрос RAM на сервере вообще перестаёт быть темой разговора, сервер лишь отдаёт файлы источнику CDN.

Astro в SSR-режиме: Node-адаптер и память в рантайме

Если вам нужен output: 'server' или output: 'hybrid' — динамические страницы, персонализация, API-роуты внутри Astro — картина меняется: теперь у вас постоянно работающий Node.js процесс, и это уже классический вопрос рантайм-памяти, а не только build-time.

С официальным @astrojs/node адаптером в режиме standalone вы получаете обычный Node HTTP-сервер:

// astro.config.mjs
import { defineConfig } from 'astro/config';
import node from '@astrojs/node';

export default defineConfig({
  output: 'server',
  adapter: node({
    mode: 'standalone',
  }),
});

Базовое потребление памяти пустого Node-процесса — порядка 60-100 МБ, дальше добавляется:

• Кэш скомпилированных страниц и модулей — обычно десятки МБ.
• Память на каждый одновременный запрос (парсинг, рендер компонентов) — зависит от сложности страницы и того, сколько данных вы подгружаете на запрос (походы в БД, внешние API).
• Утечки при неаккуратной работе с соединениями к БД или долгоживущими подписками — как и в любом Node-приложении.

Для небольшого SSR-сайта с умеренным трафиком реалистичный минимум — 1-2 ГБ RAM, для сайта с заметной посещаемостью и несколькими воркерами (через PM2 cluster mode или несколько контейнеров за балансировщиком) — 2-4 ГБ. Если ваш SSR активно ходит в базу данных на каждый рендер — добавляйте память отдельно под саму БД, это отдельная статья расходов.

Пример systemd-юнита для Node-адаптера в проде:

[Unit]
Description=Astro SSR server
After=network.target

[Service]
Type=simple
User=www-data
WorkingDirectory=/var/www/example.com
Environment=HOST=127.0.0.1
Environment=PORT=4321
Environment=NODE_ENV=production
ExecStart=/usr/bin/node ./dist/server/entry.mjs
Restart=on-failure
MemoryMax=1536M

[Install]
WantedBy=multi-user.target

MemoryMax в systemd — полезная страховка: если процесс начнёт утекать по памяти из-за бага в коде, systemd убьёт и перезапустит его раньше, чем ляжет весь сервер.

Какой VPS выбрать под Astro

Итоговый выбор конфигурации зависит от того, какой у вас режим (static/SSR) и что происходит на сервере кроме самого Astro — сборка на этом же сервере, база данных, другие сайты.

Практический совет: если есть выбор, выносите сборку в CI/CD, а на боевой сервер деплойте уже готовый dist/. Это снимает главный пиковый потребитель RAM с продакшен-сервера, и тогда даже под статику с картинками хватит 1-2 ГБ — CI-раннер (например, GitHub Actions) даёт под сборку куда больше памяти бесплатно, чем стоит держать этот запас постоянно на VPS.

Если делаете деплой прямо на VPS через git-хук — посмотрите настройку автодеплоя из git, это снимает часть ручной работы, но не снимает вопрос памяти на build: сборка всё равно происходит локально на сервере.

Типичные проблемы с памятью и как их решить

JavaScript heap out of memory на npm run build. Самая частая причина — VPS с 1 ГБ RAM без свопа и с content collections или Sharp-обработкой картинок. Решения по приоритету: (1) увеличить тариф VPS, (2) вынести сборку в CI, (3) как временная мера — настроить своп-файл хотя бы на 2 ГБ, чтобы сборка не падала, пока не мигрируете на более подходящий тариф. Своп не заменит RAM по скорости, но для разовой сборки — рабочий костыль.

Сборка «съедает» память и не отдаёт её обратно. Это нормальное поведение Node.js — процесс npm run build завершается и освобождает всю память сам, никаких дополнительных действий не нужно. Если после сборки память по free -h не освобождается — проверьте, не завис ли процесс сборки (ps aux | grep node), иногда Rollup/Vite в watch-режиме случайно остаётся запущенным в фоне.

SSR-процесс постепенно растёт по памяти (похоже на утечку). Проверьте: не открываете ли вы новое соединение к БД на каждый запрос без пула (используйте connection pooling), не копите ли вы что-то в модульных переменных между запросами, не забыли ли закрывать стримы/подписки. MemoryMax в systemd-юните (см. пример выше) или ограничение памяти в docker-compose — не решение утечки, а безопасная сетка, чтобы утечка не убила весь сервер, пока вы её ищете.

Сборка работает медленно и упирается в память при параллельном деплое нескольких сайтов на одном VPS. Если на одном сервере несколько Astro-проектов и вы пушите деплой одновременно — сборки конкурируют за RAM. Либо разносите деплои по времени, либо переходите на CI-сборку, либо увеличивайте тариф — совмещать несколько параллельных npm run build на 2 ГБ RAM не стоит даже пробовать.

Частые вопросы