Привет, Хабр! На связи команда Рег.облака. Мы запустили программу Free Tier полнофункционального облака с бесшовным переходом в основную инфраструктуру. Теперь любой желающий может заказать абсолютно бесплатно облачный сервер с минимальной конфигурацией с одним виртуальным ядром, 1 ГБ оперативной памяти и 10 ГБ пространства на NVMe-накопителе на срок до 6 месяцев и с возможностью ее расширения по запросу. 

Но статья не об этом. Один-два гигабайта — ресурс ограниченный. И сегодня мы попытаемся разобраться, что в него помещается, какой стек выбрать, на чем можно сэкономить, а на чем не стоит. Будет полезно всем, кто работает с недорогими VPS или оптимизирует расходы на ИТ-инфраструктуру.

Навигация по тексту

• Что под капотом

• Арифметика одного (и двух) гигабайт

• Что помещается: шпаргалка по потреблению памяти

• Сколько держит: нагрузочный тест

• Сценарий 1. MVP и прототипы

• Сценарий 2. Внутренние инструменты и автоматизация

• Сценарий 3. Тестовый стенд

• Как выжать максимум из минимального сервера

• А вот когда Free Tier уже не достаточно

Что под капотом

Бесплатный сервер живет в той же инфраструктуре, что и платные ресурсы: Intel Xeon, NVMe-диски, та же сеть, тот же гипервизор. Все пользователи работают на одном и том же оборудовании — машина получает публичный IP и работает как любой другой инстанс. Программа устроена в два шага:

Базовая конфигурация подходит для знакомства с платформой и легких задач. Но если проект чуть серьезнее — бот с базой данных, тестовый стенд с Docker, MVP с несколькими сервисами — стоит сразу запросить расширенную конфигурацию. Второе ядро и удвоенная память открывают заметно больше сценариев, а три месяца — достаточный срок, чтобы обкатать идею и принять решение. Если проект перерос Free Tier, переход на платный тариф — пара кликов, без миграции данных и смены IP.

Мы также готовим следующие этапы программы: FT2 с расширенными конфигурациями (2 vCPU / 2 ГБ / 10 ГБ или 1 vCPU / 2 ГБ / 20 ГБ) и ispmanager one для тех, кому удобнее работать через веб-панель, и FT3 — конфигурация 2 vCPU / 4 ГБ / 40 ГБ с S3, ИИ-токенами и ispmanager lite для B2B-сегмента. Заявки на FT2 уже принимаем.

Арифметика одного (и двух) гигабайт

Прежде чем что-то запускать, стоит понять, сколько памяти «съедает» система и какой бюджет остается приложениям. На Ubuntu 24.04 с минимальным набором сервисов:

Разница существенная. На одном гигабайте приходится тщательно выбирать стек и тюнить каждый сервис. На двух — можно работать с привычными инструментами без компромиссов. С сайтами логика та же: один легкий сайт (корпоративный, визитка, блог на WordPress с минимумом плагинов) на 1 ГБ поднимается без проблем, если не ждать шквала трафика. Несколько сайтов на одной машине, особенно на CMS с плагинами и фоновыми задачами, — уже история для 2 ГБ, где каждый nginx-virtual host и пул php-fpm получает свой запас памяти.

Что происходит, если не влезли

Если процессы суммарно запросят больше памяти, чем есть на сервере, ядро Linux включает OOM-killer и убивает самый «прожорливый» процесс. На 1 ГБ это особенно заметно: один всплеск трафика, тяжелый запрос к базе или фоновая задача — и nginx, PostgreSQL или приложение уходит в SIGKILL без предупреждения.

Есть страховочный механизм — swap. Это область на диске, которую ядро использует как дополнительную память: когда физической RAM не хватает, редко используемые страницы выгружаются туда. На NVMe-дисках накладные расходы минимальны, и это спасает от внезапных падений. Но swap — не замена оперативной памяти: если активные процессы начинают в него попадать, производительность проваливается в разы. Задержки на операциях с памятью растут с наносекунд до миллисекунд, и приложение формально живет, но фактически тормозит.

Вывод: на 1 ГБ swap нужен обязательно как подушка безопасности (конкретная настройка — в разделе с практическими советами ниже), но закладываться на то, что он вытянет постоянную нагрузку, нельзя. Если стек регулярно уходит в swap — это сигнал, что пора запрашивать расширенную конфигурацию.

Что помещается: шпаргалка по потреблению памяти

Типичные значения для популярных сервисов при небольшой нагрузке:

На 800 МБ уживаются nginx + Python-приложение + PostgreSQL — но без Redis и без запаса на пиковые нагрузки. На расширенной конфигурации с 2 ГБ тот же стек работает с запасом, и остается место для кеша, воркеров или мониторинга.

Сколько держит: нагрузочный тест

Арифметика памяти — это половина картины. Вторая половина — сколько запросов в секунду конфигурация реально выдерживает. Прогнали простой сценарий: FastAPI, один POST-эндпоинт, Ubuntu 24.04, стандартные настройки. Нагрузку давали через wrk, замеряли RPS и p95 — задержку, ниже которой укладываются 95 % запросов.

Что из этого видно? На базовой 1-1-10 простой отдающий сервис (health-чек, статический API, легкий прокси) спокойно держит сотни запросов в секунду — ограничением становится процессор, а не память. Но как только появляется полноценная БД, картина меняется: PostgreSQL начинает конкурировать за память и CPU с приложением, и на пиках уже ловятся 5xx-ошибки. На 2-2-10 того же API с PostgreSQL хватает на стабильные 500 RPS с запасом по ресурсам.

Вывод: для лендинга, MVP с SQLite, Telegram-бота или прокси-сервиса базовой конфигурации хватает с головой. Если проект предполагает реляционную базу и хоть какую-то заметную нагрузку — лучше сразу идти на расширенную, не тратя время на тюнинг того, что решается дополнительным гигабайтом.

Сценарий 1. MVP и прототипы

На старте проекта каждый рубль на счету — и логично направить бюджет в продукт, а не в инфраструктуру. Free Tier позволяет развернуть бэкенд, поднять базу данных и выкатить сервис на публичный адрес без затрат на серверы.

Ключевое отличие от локальной разработки — сервис сразу доступен извне. Можно привязать домен, дать ссылку первым пользователям и собрать обратную связь на реальном трафике, а не на localhost.

На базовой конфигурации (1-1-10) получится поднять легкий стек: статический фронтенд + API на Go или Python + SQLite. Если в MVP нужны PostgreSQL, Redis и фоновые воркеры — лучше сразу запросить 2-2-10: два ядра и два гигабайта позволяют не экономить на архитектуре и сфокусироваться на продукте.

Когда MVP подтвердил востребованность, масштабирование происходит в рамках той же платформы.

Пример. Два разработчика строят SaaS для генерации коммерческих предложений. Начинают на 1-1-10 с Caddy + FastAPI + SQLite — потребление около 100–150 МБ. Через две недели появляется потребность в полнотекстовом поиске и очереди задач. Добавляют PostgreSQL и Redis — на одном гигабайте стек уже не помещается. Запрашивают апгрейд до 2-2-10, разворачивают полный стек с запасом, привязывают домен и пускают тридцать бета-тестеров. Если к концу бесплатного периода продукт подтвердил спрос — переходят на платный тариф. 

Сценарий 2. Внутренние инструменты и автоматизация

В любой команде есть задачи, которые не дотягивают до отдельного проекта: бот для напоминаний, скрипт сбора метрик, cron-задача для отчетов. Обычно их запускают на рабочем ноутбуке — и они умирают вместе с закрытой крышкой.

На базовой конфигурации помещаются два-три легких сервиса: пара ботов и cron-скрипт. Если хочется собрать на одном сервере целую связку инструментов — мониторинг, автоматизацию и бота — расширенная конфигурация с 2 ГБ даст для этого пространство.

Что помещается на 1-1-10:

• два-три Telegram/Slack-бота (30–50 МБ каждый);

• cron-скрипты для сбора данных и отправки отчетов;

• скрипты мониторинга или healthcheck-сервис (~50–150 МБ).

Что комфортно работает на 2-2-10:

• всё перечисленное выше одновременно;

• n8n или Huginn для автоматизаций (~150–300 МБ);

• Gitea или Forgejo для небольшой команды (~100–150 МБ);

• несколько Docker-контейнеров.

Пример. Аналитик написал Python-скрипт: раз в месяц собирает данные из пяти рекламных кабинетов и отправляет сводку в корпоративный мессенджер. Начали с 1-1-10 — скрипт отлично работает по cron. Потом команда добавила бота для дежурных и Uptime Kuma для мониторинга клиентских сайтов. Когда стало тесновато — запросили 2-2-10 и развернули всё на одном сервере.

Сценарий 3. Тестовый стенд

Тестировать обновления на продакшне — конечно, плохая идея, но создавать отдельный платный стенд ради пары прогонов тоже расточительно. Еще хуже — поднимать тестовую среду локально: окружение отличается от боевого, и баги, пойманные на ноутбуке, не воспроизводятся в продакшне.

Free Tier закрывает этот сценарий. Тестовый сервер живет в той же экосистеме, что и продуктивный, — одинаковые образы ОС, одинаковая сеть. Ресурсы Free Tier можно включить в приватную сеть с другими ресурсами Рег.облака — тестовый стенд будет максимально приближен к боевому окружению.

Для smoke-тестов и проверки отдельных компонентов хватит 1-1-10. Если нужно развернуть полноценную копию приложения с базой данных и прогнать нагрузочный тест — стоит запросить 2-2-10 или 1-2-20 (второй вариант дает 20 ГБ диска, что важно при работе с дампами).

Пример. Интернет-магазин готовит новый фильтр каталога. Команда запрашивает 1-2-20, разворачивает копию с дампом базы, прогоняет 500 тестовых запросов, находит узкое место в кешировании. Исправляют — и выкатывают в продакшн.

Как выжать максимум из минимального сервера

Эти рекомендации работают не только для Free Tier, но и для любых серверов с ограниченными ресурсами. Впрочем, если задача позволяет, самый простой способ выжать максимум — запросить расширенную конфигурацию и не тратить время на оптимизацию того, что можно решить дополнительным гигабайтом.

Настройте swap

С одним гигабайтом RAM swap обязателен. Он не заменит оперативную память по скорости, но спасет от OOM-киллера при пиковых нагрузках. На NVMe штраф за обращение к swap минимальный.

fallocate -l 512M /swapfile

chmod 600 /swapfile

mkswap /swapfile

swapon /swapfile

echo '/swapfile none swap sw 0 0' >> /etc/fstab

echo 'vm.swappiness=10' >> /etc/sysctl.conf

sysctl -p

swappiness=10 означает, что ядро будет использовать swap только при дефиците свободной памяти — именно то, что нужно на NVMe. На расширенной конфигурации с 2 ГБ swap тоже не помешает, но острой необходимости уже нет.

Затюньте PostgreSQL под малый объем RAM

Дефолтные настройки PostgreSQL рассчитаны на сервер с запасом ресурсов. На 1 ГБ стоит выставить:

shared_buffers = 64MB

work_mem = 2MB

maintenance_work_mem = 32MB

effective_cache_size = 256MB

max_connections = 20

На 2 ГБ можно позволить себе более щедрые настройки — shared_buffers = 256MB, work_mem = 4MB — и PostgreSQL начнет работать заметно отзывчивее.

Или рассмотрите SQLite — для нагрузок до ~100 записей в секунду он справляется без отдельного процесса и не потребляет RAM сверх приложения. Litestream решает проблему бэкапов, реплицируя WAL в S3.

Выбирайте легкие альтернативы

Не тащите Docker, если не нужен

Docker-демон и контейнерный рантайм расходуют 50–100 МБ сверху. На базовой конфигурации с 1 ГБ это ощутимо — systemd-юниты справятся проще и экономнее. На расширенной конфигурации с 2 ГБ Docker уже вписывается: можно запустить docker compose с двумя-тремя сервисами.

Следите за потреблением

На сервере с 1 ГБ каждый процесс на счету. Привычка мониторить расход поможет поймать утечки до того, как сработает OOM-киллер:

# Топ процессов по памяти

ps aux --sort=-%mem | head -15

# Мониторинг в реальном времени

htop

А вот когда Free Tier уже не достаточно

Ограничения стоит понимать заранее:

• тяжелые базы данных с большими объемами данных — PostgreSQL будет работать, но при активной нагрузке и/или большом количестве данных даже 2 ГБ RAM станут узким местом;

• ML-инференс и ресурсоемкие вычисления — двух ядер не хватит;

• продакшн-трафик свыше нескольких сотен запросов в минуту;

• хранение больших объемов — 20 ГБ на диске (в конфигурации 1-2-20) заканчиваются быстро, если речь о медиафайлах.

Для задач посерьезнее есть платные конфигурации, на которые можно перейти в любой момент без миграции. А для юрлиц мы готовим FT3 с конфигурацией 2 vCPU / 4 ГБ / 40 ГБ, S3 и ИИ-токенами.

Для получения сервера нужна идентификация — разовый платеж 100 ₽, который возвращается или остается на балансе. После этого сервер готов к работе. Если понимаете, что задача требует больше ресурсов, то можно запросить  расширенную конфигурацию через техподдержку.

1 vCPU и 1 ГБ RAM — достаточно, чтобы начать. 2 vCPU и 2 ГБ — достаточно, чтобы не отвлекаться на ограничения и сосредоточиться на проекте. Какой самый полезный сервис вам удавалось запустить на минимальном железе? Делитесь кейсами в комментариях!