VPSРейтинг
Разработка13 августа 2026 · 13 мин

Где разместить приложение: PaaS в России 2026

Приложение написано (SaaS, API, fullstack-проект или сайт на Next.js), и его нужно запустить в продакшене. Аренда VPS добавляет к разработке вторую роль, системного администратора. Разбираем альтернативу: платформы, которые принимают код и берут инфраструктуру на себя.

1. Что такое PaaS и когда он вам не подойдёт

PaaS расшифровывается как platform as a service, «платформа как услуга». Модель простая: вы передаёте исходный код, инфраструктура остаётся зоной ответственности платформы. Она определяет, на чём написано приложение, собирает его в контейнер, запускает, выдаёт адрес с HTTPS и перезапускает процесс при сбое.

Для сравнения, стандартный путь на VPS: арендовать сервер, обновить пакеты, поставить Nginx, настроить его как обратный прокси, выпустить сертификат через certbot, написать unit-файл для systemd, поднять базу, настроить бэкапы. Всё перечисленное выполняется до первого запуска приложения в продакшене.

У модели есть и обратная сторона. Разобрать её стоит до переезда, а не после.

Когда PaaS не подойдёт

  • Нужен root. Своё ядро, модули, системные настройки, iptables: ничего этого нет.
  • VPN и прокси. WireGuard, Xray, MTProto требуют своих портов и сетевого стека. Только VPS.
  • Готовые self-hosted сервисы. Nextcloud, Jellyfin, Vaultwarden, Gitea хранят данные на локальном диске, поэтому модель PaaS для них не подходит.
  • Игровые серверы и почта. Нужны нестандартные порты и постоянное хранилище.
  • Большой объём файлов на диске. Если приложение пишет локально гигабайты, потребуется постоянный диск, которого в этой модели нет.

Если ваша задача в этом списке, вам нужен полноценный сервер, смотрите рейтинг VPS-провайдеров. Остальные сценарии, где приложение обращается к базе и отвечает по HTTP, для PaaS подходят.

2. Что именно вы размещаете

Платформы описывают себя схожими словами, но требования у проектов разные. Определите свой тип: от него зависит, на какие параметры смотреть в сравнении.

🧩 SaaS или fullstack

Django, Laravel, Next.js с бэкендом. Нужна managed-база и внятная работа с переменными окружения. Файлы пользователей сразу в S3.

🔌 API-сервис

FastAPI, Express, Go-сервис. Самый простой случай: состояние в базе, на диск ничего не пишется. Смотрите на лимит запросов в тарифе.

Фронтенд и статика

React, Vue, Astro, лендинг. Здесь важны сборка из ветки, CDN и превью-окружения для пул-реквестов.

⚙️ Фоновые задачи

Обработчик очереди, парсер, планировщик. Домен не нужен, нужен постоянно работающий процесс с автоматическим перезапуском при сбое.

У всех четырёх сценариев общая черта: приложение не хранит важные данные на локальном диске. Это основное условие, при котором модель PaaS работает.

3. Сравнение платформ

Четыре платформы, доступные из России и принимающие оплату в рублях. Данные приведены на август 2026 года, актуальные цены проверяйте на сайтах платформ.

ПараметрHostimAmveraRelaxDevTimeweb Cloud Apps
Деплойgit push, Nixpacks или свой Dockerfilegit push, amvera.yaml или Dockerfile, загрузка через панельgit push с автоопределением стека, любой Docker-образGitHub, GitLab, Bitbucket, Dockerfile или публичный образ с Docker Hub
Базы данных8 движков: PostgreSQL, MySQL, MariaDB, MongoDB, ClickHouse, Redis, KeyDB, DragonflyPostgreSQL, MySQL, MongoDB, Redis (отдельным тарифом)Кластер БД включён в тарифОтдельный сервис облачных БД
Постоянный дискНет, только внешнее S3Есть: папка /data переживает пересборкуНе заявленНе заявлен, файлы в отдельном S3
РегионРоссияМосква и ВаршаваРоссияНе указан в описании услуги
Внешние APIOpenAI, Anthropic, Telegram API доступны на уровне инфраструктурыOpenAI и Claude через зарубежные адресаНе заявленоНе заявлено
Цена в месяц590 / 1490 / 3490 ₽ за проектПриложения 170–7750 ₽, базы от 290 ₽Free tier, PRO 990 ₽, PRO Team 2450 ₽Почасовая тарификация, от 1 ₽

Внимательнее всего смотрите на строку «Постоянный диск»: от неё зависит, потребуется ли править код приложения перед переездом.

4. Разбор: кому какая подходит

HostimУниверсальный выбор по умолчанию

hostim.app

Платформа устроена вокруг проекта: внутри одного проекта вы поднимаете сколько угодно сервисов и баз, а тариф платите за проект целиком. Сервисы делятся на два типа: Web (получает домен и сертификат) и Worker (фоновый процесс без входящих запросов). Разделение удобное: бот на long-polling запускается как воркер, бот на webhook как веб-сервис, и фоновую задачу не нужно оформлять как веб-приложение.

Отдельно сильны базы: восемь движков, включая ClickHouse для аналитики и три Redis-совместимых хранилища, с ежедневными бэкапами. Стек платформа определяет сама через Nixpacks, но можно положить в репозиторий свой Dockerfile и собирать по нему.

Отдельно отметим доступность внешних API. Обращения к OpenAI, Anthropic и Telegram API работают из коробки: доступность обеспечена на уровне инфраструктуры, обходить ограничения самому не нужно. На обычном сервере в России это требует отдельной настройки.

Главных ограничений два. Файловая система эфемерна: постоянных томов нет, файлы нужно складывать во внешнее S3. И деплой идёт только из git-репозитория, готовый образ с Docker Hub не развернуть.

AmveraЕсли нужен постоянный диск

amvera.ru

Единственная из четырёх, где постоянное хранилище прямо описано в документации: папка /data монтируется в контейнер и переживает пересборку. Туда можно положить SQLite-базу, логи или загрузки пользователей, то есть всё, что на других платформах потребовало бы S3 и правок в коде. Обратите внимание: каталог приложения /app при этом не постоянный, пути нужно указывать абсолютные.

Деплой идёт командой git push amvera master с конфигом amvera.yaml или своим Dockerfile; можно и просто загрузить файлы через панель. Ещё одна особенность: выбор региона между Москвой и Варшавой. Если проекту нужен европейский адрес, у остальных платформ такого варианта нет. Запросы к OpenAI и Claude, как и на Hostim, проходят через зарубежные адреса без отдельной настройки.

Тарифная сетка мелко нарезана: младший тариф приложения даёт 0,1 CPU, 100 МБ RAM и 2 ГБ SSD за 170 ₽, а старший 3 CPU и 9 ГБ RAM за 7750 ₽. Базы тарифицируются отдельно, от 290 ₽ за 0,25 CPU и 500 МБ RAM. Итоговую сумму стоит считать заранее: приложение и база оплачиваются как два тарифа.

RelaxDevЕсли фронтенд и работа по веткам

relaxdev.ru

Платформа позиционирует себя как российскую альтернативу Vercel, и набор возможностей этому соответствует: превью-окружение для каждой ветки, раздача статики через CDN, запуск любого Docker-образа. Стек определяется автоматически, из коробки заявлены Next.js, Nuxt, Astro, Vue, React, а также Python, Node.js, Go и PHP.

Есть бесплатный тариф и 14 дней полного доступа ко всем возможностям, так что попробовать можно без оплаты. Дальше PRO за 990 ₽ в месяц (10 проектов, кластер БД, до 100 деплоев и миллиона запросов в сутки) или PRO Team за 2450 ₽ для командной работы. Дополнительные домены оплачиваются отдельно, по 150 ₽ за каждый сверх включённых.

Timeweb Cloud AppsЕсли вы уже в экосистеме

timeweb.cloud

App Platform входит в облако Timeweb, и в этом её основная ценность. В одной панели доступны облачные базы, S3-хранилище, Kubernetes и обычные серверы: если проекту понадобится VPS или отдельный DBaaS, всё останется в том же аккаунте. Деплой идёт из GitHub, GitLab и Bitbucket, по своему Dockerfile или прямо из публичного образа на Docker Hub; приватные репозитории образов при этом не поддерживаются. Технический домен с сертификатом Let’s Encrypt выдаётся сразу.

Список поддерживаемых фреймворков самый широкий из четырёх: помимо фронтенда (Next.js, Angular, Vue, Svelte, статика) отдельными инструкциями описаны Express, Fastify, Nest, Spring, ASP.NET, Gin, Beego, Phoenix и Ktor.

Тарификация почасовая и зависит от выбранной конфигурации: фиксированной сетки, как у остальных платформ, нет, поэтому сравнить стоимость заранее сложнее. Файлы, как и на Hostim, нужно выносить в отдельное объектное хранилище.

Короткий итог

  • Приложение с базой и без файлов на диске → Hostim. Предсказуемый тариф за проект, самый широкий выбор баз, доступные API OpenAI, Anthropic и Telegram API.
  • Приложение пишет на диск или нужен европейский регион → Amvera, из-за папки /data и площадки в Варшаве.
  • Фронтенд, лендинг, работа по веткам → RelaxDev. Превью-окружения и бесплатный старт.
  • Уже пользуетесь Timeweb → Cloud Apps, чтобы не разносить инфраструктуру по разным аккаунтам.

5. Что проверить до переезда

Пять вопросов, которые стоит закрыть до переезда, а не после запуска.

1. Приложение что-нибудь пишет на диск?

Загрузки, кэш, сгенерированные PDF, SQLite. Всё это надо перенести в базу или S3, либо выбрать платформу с постоянным диском.

2. Нужен ли доступ к базе снаружи?

Если требуется подключаться к продакшен-базе из DBeaver или снимать дампы локально, уточните это до оплаты. На части платформ база доступна только сервисам внутри проекта.

3. Откуда платформа выходит в интернет?

Важно, если приложение обращается к внешним API с региональными ограничениями: биржи, платёжные шлюзы, зарубежные сервисы. Белый список IP на PaaS, как правило, недоступен.

4. Как привязывается домен и что с почтой?

Технический домен выдаётся сразу, собственный подключается через DNS. Отправку писем почти всегда придётся вести через внешний SMTP-сервис: собственный почтовый сервер в этой модели не поднять.

5. Как вы будете уходить с платформы?

Держите в репозитории Dockerfile, а конфигурацию храните в переменных окружения. Тогда переезд на VPS или другую платформу не потребует переработки проекта.

6. Как выглядит деплой на практике

Платформы разные, но требования к репозиторию у них почти одинаковые. Разберём на примере API на FastAPI, а следом соберём тот же минимум на Node.js: отличаются только имена файлов.

Зависимости должны быть записаны в манифест. Платформа собирает приложение на чистой машине: то, что установлено только у вас локально, туда не попадёт.

requirements.txt (версии возьмите свои, из pip freeze)
fastapi==0.115.0
uvicorn==0.32.0
psycopg[binary]==3.2.3

Версии здесь для примера, подставьте те, на которых приложение работает у вас: pip freeze > requirements.txt. Диапазоны вроде fastapi>=0.115 на продакшене лучше не использовать: очередная сборка может подтянуть новую мажорную версию и сломаться без изменений с вашей стороны.

Приложение слушает порт из переменной окружения и адрес 0.0.0.0, а не localhost. Это причина большинства ошибок 502 при первом деплое: приложение запустилось, но платформа не может к нему подключиться.

Команда запуска
uvicorn main:app --host 0.0.0.0 --port $PORT

Настройки читаются из окружения, а не из файла в репозитории. Адрес базы, ключи и токены задаются в панели платформы и в git попадать не должны.

main.py (фрагмент)
import os

DATABASE_URL = os.environ["DATABASE_URL"]   # адрес базы выдаёт платформа
SECRET_KEY = os.environ["SECRET_KEY"]       # задаётся в панели, в git не хранится

То же самое на Node.js

Минимальный сервис на Express, который развернётся на любой из четырёх платформ без правок. Три файла: package.json, package-lock.json (создаётся сам при npm install и обязательно коммитится) и server.js.

package.json
{
  "name": "my-api",
  "private": true,
  "type": "module",
  "engines": {
    "node": ">=22"
  },
  "scripts": {
    "start": "node server.js"
  },
  "dependencies": {
    "express": "5.1.0"
  }
}

Два поля здесь критичны. Поле scripts.start задаёт команду, которой платформа запускает приложение: без неё сборка пройдёт, а контейнер не стартует. engines.node фиксирует версию рантайма, иначе платформа выберет её сама и может взять не ту, на которой вы разрабатывали.

server.js
import express from 'express'

const app = express()

// порт выдаёт платформа, локально берём 3000
const port = process.env.PORT || 3000

// настройки только из окружения, не из файла в репозитории
const databaseUrl = process.env.DATABASE_URL

app.get('/', (req, res) => {
  res.json({ ok: true, db: Boolean(databaseUrl) })
})

// эндпоинт для health-check платформы
app.get('/healthz', (req, res) => {
  res.status(200).send('ok')
})

// 0.0.0.0, а не localhost, иначе платформа не достучится и отдаст 502
app.listen(port, '0.0.0.0', () => {
  console.log('listening on port ' + port)
})

Проверить локально до деплоя: npm install && PORT=8080 npm start, после чего приложение должно отвечать на http://localhost:8080/healthz. Для фоновой задачи вместо веб-сервиса блок app.listen не нужен, а сервис на платформе создаётся типом worker.

Дальше делаете git push. Платформа определит стек, соберёт образ, запустит контейнер и проверит, что приложение отвечает. Если проверка не прошла, трафик останется на предыдущей версии, и это основное отличие от ручного деплоя через Docker Compose.

7. Частые проблемы

После деплоя всё работает, но загруженные файлы исчезли

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

Сборка прошла, но открывается 502

Как правило, приложение слушает фиксированный порт вместо $PORT или привязалось к 127.0.0.1. Проверьте команду запуска: нужен хост 0.0.0.0 и порт из переменной окружения.

Локально запускается, на платформе падает при сборке

Зависимость установлена у вас, но не записана в requirements.txt или package.json. Проверяется просто: склонируйте репозиторий в чистую папку и установите зависимости с нуля, и ошибка воспроизведётся локально.

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

Смотрите также