Представьте ситуацию: вы в одиночку или вместе с командой запускаете своё приложение или сервис, и через какое‑то время инструмент, с которого вы стартовали для проверки гипотезы (например, тот же Lovable) становится тесен. Это значит, что пора переходить на другой. Но какой? Vercel? Railway? Fly.io? Porter? Или всё же остановить свой выбор на Heroku? Эти платформы обещают примерно одно и то же — «просто дай код, нажим кнопку, чтобы задеплоить, а мы разберёмся». И уже потом внезапно оказывается, что один инструмент не подходит под ваш профиль трафика, у другого философия релизов не ложится на культуру команды, у третьего управляемая БД — это на самом деле не совсем managed.
Герои магии и меча этой статьи: Heroku, Vercel, Fly.io, Railway и Porter. Они появлялись на рынке именно в этом порядке, и такая последовательность отражает то, как менялись подходы к построению приложений за последние пятнадцать лет. Каждая платформа в своё время решала конкретную боль индустрии, и это намертво вшито в архитектуру решения.
В этой статье я рассмотрю платформы последовательно с учетом их времени их появления, вводимых ими абстракций, постараюсь раскрыть смысл данных абстракций и как это влияет на архитектуру разрабатываемых приложений.
Что в статье и что за рамками
Начну с того, что прошлой статье я описал четыре этапа зрелости приложения и их влияние на команды разработки. Плюс там же упоминал, что разберу две абстракции, заслуживающие отдельного обсуждения, — dyno в Heroku и serverless runtime в Vercel. Но в процессе подготовки я решил расширить рамки и рассмотреть основные платформы, соответствующие второму и, условно, «второму с половиной» уровням зрелости.
Напомню, что после этапа старта продукта в случае успеха команда обычно приходит к следующим уровням развития. Проверка гипотезы позади — нужны предсказуемая сборка, повторяемый деплой, работа с окружениями. Так вот платформы условного 2-го уровня решают одну и ту же задачу: сделать доставку в продакшен предсказуемой. Но, как увидим, решают её очень по‑разному.
И сразу о том, что осталось за рамками. На рынке есть ещё несколько категорий платформ, которые я намеренно не разбираю в этой статье:
Self‑hosted single‑host PaaS для индивидуальных разработчиков: Dokku, Coolify, CapRover, Dokploy. Сознательно ограничены одним сервером — инструменты под конкретный сценарий: один разработчик, один сервер, один продукт с ограниченными возможностями масштабирования.
Прямые конкуренты каждой из разбираемых платформ в её нише — им посвящён сводный блок «Карта рынка по категориям».
Полноценные IDP (internal developer platforms) для организаций со 100+ сервисами: Backstage, Port, Humanitec, VK Dev Platform, «Сфера.Портал разработки». Это прям отдельный класс инструментов.
Тарификацию и биллинга каждого решения затрону только по верхам.
Хронология. Пять платформ — пять эпох
Прежде чем погрузиться в детали, полезно сразу увидеть, в каком порядке появлялись наши герои. Порядок не случаен, и каждая платформа несёт на себе отпечаток своей эпохи.
2007 | 2016 | 2017 | 2020 | 2020 |
|---|---|---|---|---|
Heroku | Vercel | Fly.io | Railway | Porter |
Rails‑монолиты, Twelve‑Factor App, buildpacks | Jamstack + Next.js, CDN‑first, иммутабельные деплойменты | Edge CDN → full‑stack edge, multi‑region “из коробки” | Современный full‑stack PaaS “с чистого листа”: проект‑контейнер, visual canvas | Миграция c Heroku в своё облако Bring Your Own Cloud (BYOC) по умолчанию |
Из этого расположения сразу видно две вещи. Во‑первых, между Vercel (2016) и Railway с Porter (2020) прошло всего четыре года, но за это время сильно изменилось то, как команды строят приложения: монолиты уступили место микросервисным архитектурам, появились нормативные требования, выросли бюджеты на облачные ресурсы. Во‑вторых заметно, что некоторые продукты, например Fly.io в 2017 году изначально стартовала как edge CDN для разработчиков, постепенно обрастая PaaS‑фичами для разработки. А полноценной платформой стала позже — где‑то 2020–2021 году. Эта особенность определила её архитектуру: anycast и multi‑region встроены в фундамент решения.
Почему именно эта пятёрка
У каждого решения есть прямые конкуренты в своей нише. Я взял именно данные платформы как наиболее показательных представителей категории.
Классический PaaS для долгоживущих процессов. Тут стандарт задала, конечно же, Heroku. Её наследники — Render, DigitalOcean App Platform. Все они usage‑based PaaS с похожей моделью.
Jamstack и CDN‑first. Тут флагмен Vercel, особенно для Next.js. Прямой конкурент — Netlify (не привязан в конкретному фреймворку, ярче выражен на этапе сборки, слабее в бессерверной среде исполнения).
Edge VM и global compute. Fly.io — наиболее зрелый представитель категории. Главный конкурент — Cloudflare Workers + Durable Objects + R2 (где edge functions → edge state, тогда как Fly.io: VMs → edge VMs). Из гиперскейлеров — AWS App Runner, Cloud Run, Azure Container Apps: похоже, но без anycast‑сети и Machine API.
Современный full‑stack PaaS. Тут герой Railway. Прямые конкуренты — Render и DigitalOcean App Platform. Да, вы верно подметили, что эти ребята уже были в 1-й категории. Действительно разница между на текущий момент минимальная и в заключается в основном во времени появления платформы и задач, которые они решали. Архитектурные различия небольшие, разница в основном в UX (тут кажется у Railway конкурентов мало)
BYOC PaaS на Kubernetes. Наиболее показательный представитель категории — Porter. Прямые конкуренты — Qovery, Northflank, Flightcontrol, Spectro Cloud Palette. Различаются деталями биллинга, уровнем административного регулирования и стратегии использования разных облачных платформ. Решают одну и ту же задачу — предоставление платформенного UX поверх Kubernetes в облачном аккаунте клиента.
Рынок сейчас не такой, как 10 лет назад, когда Heroku была единственным вариантом. В каждой нише есть несколько серьёзных игроков, и выбор зависит даже не от категории, а в основном от ограничений: используемых фреймворков, нормативных требований, доступных бюджетов.
Сравним в плоскости простота и контроль
Если попытаться расположить нашу пятёрку на одной плоскости, самая очевидная пара осей — простота использования и контроль (насколько глубоко можно дотянуться до базовой инфраструктуры: регионов, VM, kubectl, AWS‑сервисов, которые «под капотом»).
Получается диагональ: простота и контроль обычно растут друг за счёт друга. Heroku и Vercel: “нажми кнопку — всё работает”, но почти нет доступов к инфраструктуре. Railway чуть правее: видны связи между сервисами на canvas, есть дисковые разделы, доступны переменные‑ссылки. Porter — заметный сдвиг к контролю: вы видите свой VPC, можете подключиться через kubectl, но всё ещё с UX PaaS поверх Kubernetes. Fly.io — самая правая: вы напрямую управляете машинами, регионами, локальными хранилищами — почти VPS‑уровень с PaaS‑автоматизацией.
Это самая привычная карта, но она же и самая прямолинейная. Дальше посмотрим на ту же пятёрку под двумя другими углами — там расположения будут уже не диагональными.
Сравним в плоскости где живет ваш продакшн
Сейчас мы рассмотрим одно из главных архитектурных различий — где именно работает ваше приложение и кто владеет этим контуром. От этого зависит остальное: что вы можете настраивать, кому идёт счёт за инфраструктуру, как меняется нормативка.
Heroku и Vercel работают в контуре самой платформы (физически на AWS, но с точки зрения владения это платформенный контур). Принципиальное различие Vercel — встроенный edge CDN как единая фабрика с вычислительными ресурсами, а не два соединённых сервиса.
Fly.io живёт на собственной физической инфраструктуре в дата‑центрах, расположенных в 30+ регионах мира. Anycast‑сеть и multi‑region доступны «из коробки». Railway по умолчанию работает на собственной инфраструктуре (до 2024 года на Google Cloud, далее в собственных дата‑центрах). В рамках тарифа Enterprise доступна модель BYOC: платформу можно развернуть на VPC клиента. Минимальная стоимость Enterprise — около 2000 $ в месяц, что само по себе отсекает часть аудитории.
Ключевая мысль: «где живёт продакшен» — это первая развилка при выборе платформы, и она часто определяется не техническими, а нормативными требованиями. Если ваша компания работает с зарубежным рынком и подпадает под HIPAA, SOC 2 или региональные ограничения по хранению данных — Heroku, Vercel и Fly.io отпадают, остаются Railway BYOC или Porter. Если работаете с российским рынком, всё ещё жёстче: с 1 июля 2025 года по 152-ФЗ первичный сбор персональных данных граждан РФ на зарубежных серверах — прямое нарушение и ни одна из пяти платформ этой статьи для этого не подходит. Рабочая схема — разделение стека: ресурсы на любой из платформ, хранилище ПДн граждан РФ в отдельном контуре внутри РФ (Yandex Cloud, VK Cloud, Cloud.ru). Если таких требований нет — выбор открыт.
Эту мысль удобнее рассматривать в двух осях. Первая — архитектура приложения (single‑component vs. multi‑service), вторая — размещение продакшена (контур платформы vs. контур клиента).
Здесь сразу видно: Heroku и Vercel — две доминирующие платформы 2010-х для своих ниш — находятся в нижнем левом углу. Railway и Fly.io переехали в верхнюю половину — они изначально проектировались под multi‑service. Porter единственная платформа, которая занимает правый верхний угол: и multi‑service, и в вашем cloud‑аккаунте. Vercel формально может обслуживать сложные сценарии (монорепо, микрофронтенды), но это работает с натягом — естественнее всего на нём один Next.js full‑stack‑проект.
Heroku (2007): истоки dynos и buildpacks
Heroku появилась в 2007 году, во времена Rails‑монолитов. ЦА — это стартапы на Rails, которым нужно было «просто запустить в продакшен» без системного администратора. Модель «одно приложение = монолит с web/worker/release‑процессами» — прямое отражение Rails‑архитектуры тех лет. Когда начался массовый переход на микросервисы (с 2015 года), Heroku адаптировалась не очень изящно и как следствие отсюда тянется необходимость создавать множество отдельных приложений и отсутствие приватной сети по умолчанию. При этом многие «странности» стали индустриальными стандартами, например, buildpack, который стал стандартом сборки без Dockerfile.
Главные сущности и как они связаны
Slug — упакованное приложение: код, зависимости и конфигурация в одном артефакте, готовом к запуску. Полная цепочка: push в Git → Git pre‑receive hook → сервис slug compiler на стороне Heroku запускает buildpack → на выходе получается slug (аналог OCI‑образа). В новом поколении Heroku (Fir) вместо slug — полноценные OCI‑образы через Cloud Native Buildpacks.
Buildpack — то, что превращает репозиторий в slug: определяет язык и стек, выбирает способ сборки, подтягивает окружение. Это встроенный в платформу CI‑инструмент: команде не нужны Jenkins или GitHub Actions для сборки, Heroku делает это сама.
Dyno — контейнер, в котором запускается slug. Работает на собственной оркестрации Heroku (не Kubernetes), подчиняется своим правилам: эфемерная файловая система, ежесуточный рестарт, скейлинг через heroku ps:scale. Набор запущенных dyno образует dyno formation — сколько процессов и какие сейчас крутятся.
Procfile — текстовый файл в репозитории с описанием, какие процессы и как запускаются. Аналог containers в Kubernetes, но проще: одна строка — один тип процесса. Особый случай — release‑процесс: команда запускается один раз перед каждым релизом в одноразовом dyno (например, миграции БД). Если падает — релиз не выкатывается. Для большинства приложений Procfile не обязателен: buildpack сам определит, как запустить.
Config vars — переменные окружения, управляемые платформой, а не файлом рядом с кодом (идея Twelve‑Factor App). Ключевое отличие от других платформ: изменение config var само по себе создаёт новый release и мгновенно перезапускает dyno — без пересборки.
Add‑ons — подключаемые внешние сервисы (БД, кэши, очереди, мониторинг). Подключаешь add‑on и он сам прописывает свои config vars. Например, Heroku Postgres автоматически создаёт DATABASE_URL в config vars; при ротации кредов провайдером значение переменной обновляется автоматически, dyno просто перезапускается.
И ключевая концепция, связывающая всё — Release.
Release = slug + актуальные config vars + список подключённых add‑ons
Это снимок того, что катится в прод в данный момент. Если что‑то меняется, то релизится новая версия (v12, v13, v14 и так далее). Поэтому heroku rollback v12 мгновенно возвращает не только код, но и ту конфигурацию, которая была на момент v12. Одна из самых элегантных идей в Heroku. Она переехала во многие современные платформы, включая Railway и Render.
Окружения и pipelines
Pipeline — связка из нескольких приложений Heroku, между которыми можно «продвигать» один и тот же артефакт без пересборки. Каждое окружение (dev, stage, prod) — отдельное Heroku‑приложение со своими config vars, add‑ons и dyno formation. Pipeline связывает их в логическую цепочку. При promote to production Heroku берёт тот же slug из stage и кладёт в production то есть это то, что вы протестировали, буквально тот же бинарный артефакт в проде. Это исключает возникновение ситуаций из разряда «в stage работало, в prod пересобралось и сломалось».
Review Apps — часть той же модели. Каждый PR автоматически учитывается как отдельное полноценное Heroku‑приложение со своим URL; после закрытия PR окружение удаляется. Аналог preview‑окружений в Vercel и Railway, просто называется иначе.
Балансировка нагрузки и автоскейлинг
Перед web dyno стоит Heroku Router — балансировщик со случайным алгоритмом (не циклический перебор): нет фиксации сессий, нет прогрева, есть жёсткий 30-секундный тайм‑аут (ошибка H12). Длинные запросы нужно стримить или переводить в фон. Heroku Autoscaling доступен только на старших тирах (Performance, Private, Shield), метрика — p95 response time. На младших тирах автоскейлинга нет — ручной heroku ps:scale или сторонние add‑ons.
Биллинг
Heroku тарифицирует зарезервированную мощность. Цена dyno — потолок месячного счёта за ресурсы. Шаг масштабирования дискретный: переход с одного dyno на два увеличивает счет на 100%, а не на 50%. Главный риск — оплата простаивающих мощностей (платите, даже если трафика нет); преимущество — зафиксированная предсказуемая цена. Add‑ons из Heroku Elements тарифицируются одним счётом через Heroku и создают второй параллельный биллинг рядом с dyno, часто сопоставимый по сумме с compute. Подробный разбор «лесенки» Heroku и других решений с цифрами по точкам А → Б → В → Г — разберу чуть позже в отдельной статье.
Да, мы много потратили на разбор Heroku, потому что без знакомства с buildpack и Procfile не разобраться с Railpack. Без представления, что такое slug + config vars + add‑ons = release, нельзя понять deployment в Vercel и deployment target в Porter.
Vercel (2016): когда CDN стал фундаментом
Vercel выросла из мира Jamstack и статических сайтов. Изначально называлась Now.sh, ребрендинг произошел в 2020 году. Параллельно та же команда создала Next.js — отсюда глубокая связь платформы с фреймворком. Ставка на «сборку как иммутабельный артефакт» идёт из Jamstack‑философии, CDN‑first — потому что начинали как CDN, и CDN у Vercel до сих пор не приложение к основной платформе: CDN — это основа над которое надстроен compute, а не наоборот. Это объясняет и сильные стороны Vercel (для Next.js — лучшая платформа на рынке), и слабые (иммутабельность делает feature flags и операционные изменения неудобными, но об этом позже).
Главные сущности и как они связаны
Project — главный контейнер, обычно соответствует одному репозиторию (как правило, один сайт на Next.js).
Serverless functions / runtime — базовая единица исполнения. В отличие от dyno (который позиционируется как долгоживущий процесс), Vercel‑функция это эфемерный обработчик, поднимающийся по требованию: нет запросов — нет инстансов и затрат. Внутри функции только обработчик одного маршрута.
Edge functions (функции, работающие на edge‑узлах ближайших к пользователю точках сети CDN) — код, выполняемый прямо в CDN‑узле, там, где находится пользователь. Задержка 5–20 мс глобально — механика, доступная только в том случае, если CDN собственный.
Fluid compute + Active CPU pricing — снимают классическое serverless‑ограничение «один запрос на инстанс». В классической модели I/O‑bound нагрузка (вызов к OpenAI, внешнему API) поднимает на каждый запрос отдельный инстанс, который 99% времени ждёт сеть, а биллинг идёт. Fluid compute разрешает одному инстансу обслуживать много параллельных запросов через event loop, Active CPU pricing тарифицирует только активный CPU. С апреля 2025 года включён по умолчанию; для AI‑эндпойнтов даёт кратное сокращение счёта.
Framework presets — аналог пресетов для фреймворков. Vercel определяет фреймворк более чем из 50 вариантов (Next.js, Nuxt, SvelteKit, Astro, Remix и так далее) и применяет готовую конфигурацию. Если buildpack в Heroku ориентирован на язык, то preset в Vercel — на фреймворк.
Environment variables — переменные, разделённые по типам окружения (production, preview, development). Отличие от Heroku: изменение переменной не применяется к работающим deployments — нужен явный redeploy.
Deployment — аналог release в Heroku, но иммутабельный. Это снимок, который никогда не меняется. Каждый deployment имеет уникальный URL вида myapp‑abc123xyz.vercel.app и остаётся доступным после создания — можно открыть deployment двухмесячной давности и убедиться, что там действительно был баг.
Что триггерит новый deployment
Триггер для деплоя — в первую очередь запрос в Git'е.
Что произошло | Heroku | Vercel |
Push в основную ветку | Новый slug + release в prod | Новый build + production deployment |
Push в другую ветку | Ничего | Новый preview deployment с URL |
Открыл PR | Если включены review apps‑ автоматически развёртывается временное приложение со своим URL | Автоматически создает preview deployment |
Поменял env var | Новый release без пересборки | Ничего — нужен redeploy |
Подключил сервис | Add‑on → новый release | Integration → нужен redeploy |
В Heroku release — это то, «что сейчас в проде», изменяется, если меняется код или конфигурация. В Vercel deployment — это «снимок с конфигурацией на момент сборки», менять его нельзя. Это философский выбор между операционной гибкостью (Heroku) и воспроизводимостью (Vercel). Практический нюанс: Vercel требует пересборки даже там, где она технически не нужна; для изменения конфигурации без редеплоя предлагается отдельный платный продукт — Edge Config. Он же стандартный способ реализации фича‑флагов на Vercel: без него любое переключение фича‑флага требует пересборки.
Окружения
Vercel имеет три встроенных окружения: production, preview, development, а также custom environments для пользователей тарифов Pro и Enterprise (это длительные pre‑production‑окружения вроде stage или QA). У каждого есть свой набор переменных, а развёртывание в нужное окружение триггерится событиями в Git.
Биллинг
В отличие от Heroku с её фиксированной мощностью, Vercel использует многомерную модель тарификации: compute (Active CPU + invocations), bandwidth, edge requests, image optimization, build minutes, per‑seat 20 $ за разработчика. Главный риск — «лесенка наоборот»: рост посещаемости ведет к прямо пропорциональному увеличению счёта при этом без потолка. Защита — Spend Management с soft‑уведомлениями при достижении порога (50, 75, 100%) и опциональной функцией принудительной остановки. Через webhook‑интеграцию можно настроить принудительное замедление — переключение на статическую версию сайта. Это уникальная возможность Vercel. Подробный разбор «лесенки наоборот» также отдельно.
Fly.io (2017): всё начинается с VM
Fly.io появилась в 2017 году как edge‑платформа для запуска приложений — в духе Cloudflare Workers. Если Vercel тоже вырос из CDN, то это был CDN для контента (раздать HTML и картинки ближе к пользователю), в то время Fly.io с самого начала — CDN для процессов: запустить настоящий Node.js или Go‑приложение в 30 регионах. В 2020–2021 годах произошел разворот к полноценным приложениям, а в 2021 году добавили постоянное хранилище данных. Если Heroku выросла из мира Rails‑монолитов, а Vercel — из Jamstack, то Fly.io берет начало в edge CDN. Отсюда и ключевые особенности: база — это anycast и multi‑region; VM (не приложение) — это атомарный объект. В 2024 году Fly.io запустила Fly Kubernetes Service, а в 2025 году, после завершения партнёрства с Supabase, представила собственный полноценный Managed Postgres с высокой доступностью, заменив прежнюю автоматизированную (но не полностью управляемую) версию.
Главные сущности и как они связаны
App + process group — app это логический контейнер для приложения, process group — роль внутри (web, worker, cron), описываемая в файле fly.toml. Уникальная особенность: разные process groups можно развёртывать в разных регионах. Например, web — в Лондоне и Токио, worker — только в Нью‑Йорке. Ни одна другая платформа не дает такой возможности «из коробки».
Machine — Firecracker microVM, на которой запускается приложение. Главная уникальная сущность Fly.io. У всех других платформ контейнер/VM является скрытой деталью реализации; у Fly.io Machine — это объект, которым вы напрямую владеете и управляете. Каждая ВМ имеет ID и доступна для императивных операций. fly machine start / stop / destroy управляют жизненным циклом конкретной VM. fly ssh открывает прямой shell внутрь работающей машины. Можно посмотреть процессы, потрогать файловую систему. fly machine clone ‑region syd мгновенно копирует ВМ в другой регион, и приложение уже работает в двух. Это VM‑first‑парадигма, радикально отличающаяся от app‑first у Heroku, Vercel и Railway.
Autostop и autostart Machines — уникальная фишка Fly.io. Машина может находиться в режиме ожидания, расходуя только оперативную память и не учитываясь как вычислительный ресурс, и пробуждаться при первом же запросе. Это обеспечивает автоматическое сворачивание до нуля для неактивных регионов и недорогую работу в нескольких географических зонах (можно держать 10 регионов, но платить за ресурсы только там, где есть трафик). В отличие от Vercel serverless, ВМ не уничтожается, а останавливается — Fly называет это resumeable VMs, гибрид VM и serverless‑модели.
Anycast‑сеть и Fly Proxy. Один IP‑адрес объявляется из всех регионов одновременно, трафик автоматически идёт в ближайший. Перед каждым кластером Machines стоит Fly Proxy — собственный прокси‑слой маршрутизации, доставшийся в наследство от edge CDN. Пользователь автоматически попадает в ближайший регион без настройки CDN. Fly‑replay header — еще одна особенность: приложение может вернуть Fly‑Replay: region=ams, и Fly Proxy переотправит запрос в другой регион. Используется для multi‑region patterns: «читать локально, писать в primary region».
Volumes — встроенный быстрый диск на конкретной физической машине в выбранной географической зоне, а не общее сетевое дисковое пространство. Одна виртуальная машина — один диск (соответствие 1:1), автоматическая репликация не предусмотрена — данные копирует само приложение, при аппаратном сбое диска данные теряются (есть ежедневные копии на случай восстановления, но это не полноценная репликация). Можно создать копию за секунды через мгновенный клон — это используется для preview‑окружений. Это даёт высочайшую производительность (latency в микросекундах, IOPS — десятки тысяч), но операционная ответственность за репликацию ложится на разработчика.
Managed Postgres (MPG). До 2025 года у Fly был только automated Postgres: автоматическое создание БД есть, но бэкапы и переключение при сбое на вас. UX выглядел так, как будто у вас есть управляемая БД, но фактически это было не так. После провального партнёрства с Supabase в 2025 году Fly запустил настоящий Fly MPG с HA, автоматическим переключением, encrypted backups, connection pooling. Про этот урок — в сквозном паттерне про управляемые БД ниже.
LiteFS — distributed SQLite с автоматической репликацией. Приложение работает с обычным SQLite, а LiteFS через FUSE‑файловую систему перехватывает запись и реплицирует в другие регионы. В 2024 году Fly купил Litestream — open‑source‑решение для бэкапа SQLite в S3. Серьёзная ставка на SQLite as a distributed database — необычное направление для PaaS.
Окружения и сеть
Приватная сеть через WireGuard VPN: каждое приложение получает приватный IPv6-адрес, Machines одного app общаются между собой через эту сеть. К приватной сети можно подключиться с собственного компьютера — это удобно для локальной разработки. Автоматического service discovery в стиле K8s нет, визуального canvas — тоже.
Fly.io документирует и поддерживает cell‑based architecture pattern: приложение делится на изолированные ячейки, каждая обслуживает подмножество пользователей и имеет свою БД. Middleware определяет, к какой ячейке относится запрос, и направляет его туда (через fly‑replay). Паттерн, который Amazon строит годами, а Fly предоставляет готовый блюпринт как методологический документ.
Биллинг
Fly.io имеет самую гранулярную модель — per second per resource. ВМ тарифицируется только тогда, когда реально запущена; volumes — 0,15 $ за ГБ в месяц, начисляются постоянно, независимо от состояния Machine (ключевая ловушка модели); пропускная способность 0,02 $ за ГБ для Северной Америки и Европы; Managed Postgres — от 38 $ в месяц. Скрытые издержки накапливаются: выделенный сетевой адрес (2 $ в месяц за экземпляр приложения), снимки хранилищ (тарифицируются с января 2026-го), защищённая сеть между регионами (тарифицируется с февраля 2026-го). Уникальная фича — Reservations: можно получить скидку до 40% за годовой резерв, что большая редкость для usage‑based PaaS. Главный риск — операционная ответственность: нужна дисциплина в разборе неиспользуемых ресурсов.
Railway (2020): современная full‑stack PaaS с чистого листа
Railway основана в 2020 году как «современный Heroku» для эпохи микросервисов: project как контейнер для нескольких сервисов, reference variables, приватная сеть по умолчанию, визуальный canvas — прямой ответ на боль с Heroku (много отдельных app's) и на ограничения Vercel (один проект хорошо работает только для Next.js‑стиля). В 2024 году Railway запустили проект Railway Metal — начали развёртывать собственное железо в колокейшн‑дата‑центрах в US‑West, US‑East, EU‑West и Singapore. GCP и AWS остаются в стеке параллельно.
Главные сущности и как они связаны
Project — набор связанных компонентов одного продукта (бэкенд, фронтенд, воркеры, БД, Redis). Такой концепции нет ни в Heroku, ни в Vercel в явном виде: в Heroku пришлось бы городить несколько app и связывать через pipelines, в Vercel — несколько проектов с прописанными URL друг друга. Внутри проекта живут сервисы (отдельные развёртываемые компоненты, ближайший аналог — app в Heroku). Каждый push в Git создаёт новый deployment конкретного сервиса с мгновенным откатом на любой предыдущий.
Volumes — то, чего почти не было у других. В Heroku диск dyno эфемерный, в Vercel у serverless‑функций его нет, в то время как в Railway это явная сущность: 5, 50, 500 ГБ с автоматическим переносом данных между серверами при смене расположения (в отличие от сетевых хранилищ, в Fly.io тома привязаны к конкретной машине и не переносятся автоматически). Можно прямо в проекте поднять контейнер с PostgreSQL и примонтировать к нему том.
Railpack — аналог buildpack в Heroku: сканирует репозиторий, угадывает язык или фреймворк, собирает Docker‑образ. Поддерживает Node.js, Python, Go, PHP, Java, Ruby, статические сайты. Open‑source‑проект на основе BuildKit, пришёл на смену Nixpacks в 2025 году (подробнее про индустриальное значение — в сквозных паттернах ниже). Procfile не нужен: у Railway нет задачи описывать разные типы процессов одного приложения, потому что разные процессы — это разные сервисы внутри проекта. Более чистая декомпозиция.
Variables и reference variables. Уникальная особенность — reference variables: в одном сервисе можно сослаться на переменную из другого сервиса того же проекта. Когда меняется DATABASE_URL в сервисе Postgres — все сервисы, ссылающиеся на неё, автоматически получают новое значение и редеплоятся. Это объединяет удобство Heroku (автоматическое изменение конфигурации) без недостатка Vercel (где нужен явный redeploy).
Environments. По умолчанию один environment — production. Можно создать persistent environments (stage, dev) и PR environments — временные окружения, автоматически создающиеся на каждый PR. В Railway PR‑окружение содержит все сервисы проекта, включая БД, — честный preview для бэкенд‑приложений, которого у Vercel не получить. Дополнительно есть focused PR environments для монорепозиториев: поднимаются только те сервисы, которых коснулись изменения.
Визуальный canvas
Давайте отдельно про самую узнаваемую черту Railway, концептуально отличающую её от всех других платформ.
Project Canvas является основным интерфейсом работы с проектом. Архитектура рисуется как граф: каждый сервис это карточка на холсте, между сервисами видны связи. У других платформ иначе: Heroku — табличный список приложений, Vercel — список проектов, Porter — таблично‑иерархическое представление ближе к Kubernetes‑дашбордам.
Canvas делает больше, чем просто показывает связи. Drag‑n-drop связей между сервисами автоматически инжектит нужные reference variables — визуальное соединение становится реальной связью в инфраструктуре. Поддерживается совместная работа в реальном времени и группировка по сервисам для крупных проектов (10+ сервисов). Это смена парадигмы, аналогичная тому, что Figma сделала с дизайном, а Notion — с документами: в традиционных DevOps‑инструментах инфраструктура описывается в YAML или HCL, связи выражены через имена ссылок, чтобы понять архитектуру, нужно мысленно собрать граф из текста. В Railway граф первичен, а текст вторичен. Архитектура самодокументируется, ревью изменений визуальные, на синках обсуждают canvas, а не диаграммы из draw.io.
Биллинг
Вы платите только за реально потреблённые ресурсы, которые рассчитываются до секунды: CPU, RAM, egress, volume storage. Самая гибкая модель — нет платы за неиспользуемые ресурсы (как в Heroku), нет накрутки за рабочие места пользователей и edge‑сервисы (как в Vercel). На старте Railway сильно дешевле остальных платформ. Важный нюанс про места для разработчиков: на тарифе Pro вы не платите за участников рабочего пространства при условии, что более 80% ресурсов идёт на собственную инфраструктуру Railway (Metal); с 2024 года клиенты выполняют это условие по умолчанию — для команд из 10+ человек это существенная экономия по сравнению с Vercel (20 $ × N). Главный риск — egress при масштабировании: Railway не имеет встроенного CDN, при терабайтах трафика egress становится главной статьёй расходов. Защита — Spend Limits на тарифе Pro с автоматической остановкой сервисов при достижении лимита (как Spend Management в Vercel).
Porter (2020): мост к собственному облаку для команд, выросших из Heroku
Porter с самого начала позиционировалась как инструмент для миграции с Heroku в своё облако. Воспроизводит Heroku‑модель «одно приложение с web/worker/release‑процессами» (через applications + service types), потому что миграция с Heroku — изначально центральный сценарий. Поверх — Kubernetes как инфраструктура, на которой можно расти. В 2022–2023 годах Porter отключил автоматическую регистрацию для маленьких команд, потому что не могли обеспечить качественную помощь пользователям. Уже потом построили автоматизацию и вернули, но для более серьёзной аудитории — высокая стоимость входа стала частью фильтра. В 2024 запустился Porter Cloud — отдельный продукт без вашего облачного аккаунта, с возможностью перейти из Porter Cloud в Porter BYOC без миграции данных.
Главные сущности и как они связаны
Cluster — управляемый Kubernetes кластер в вашем облачном аккаунте (EKS в AWS, GKE в GCP, AKS в Azure). Первое принципиальное отличие Porter от всех остальных платформ: в Heroku, Vercel, Railway, Fly.io нет понятия «кластер» в интерфейсе. Платформа сама решает, где запустить приложение. В Porter кластер является явной сущностью, которую вы выбираете; можно иметь несколько кластеров (для prod, staging, регионов, команд).
Application + service. Application — это главный объект, группа сервисов с общим build и общими env vars. Rails‑монолит с веб‑процессом и воркером — это одно приложение с двумя сервисами (web + worker), а не два отдельных; для разных образов нужны разные приложения. Service бывает трёх типов: web (HTTP, HTTPS), worker (фон), job (по расписанию). Прямой аналог Procfile process types в Heroku, но как явные сущности в UI, а не строки в файле — наследие изначального сценария Porter, ориентированного на миграцию с Heroku. Каждый deployment версионируется с commit hash, можно посмотреть diff конфигурации между версиями и откатиться на любую предыдущую — с preview изменений перед применением.
Datastore — БД в вашем облаке, управляемая через cloud‑native‑сервисы: RDS и ElastiCache в AWS, Cloud SQL в GCP, Azure Database. Porter поднимает реальную RDS или ElastiCache в вашем VPC, настраивает peering, управляет credentials. Принципиально другой подход, чем у Railway: у Porter БД — это native managed‑сервис с зрелыми enterprise‑фичами (multi‑AZ, automated backups, point‑in‑time recovery, IAM authentication). Уникальная фича — Aurora Fast Cloning для превью: при создании PR‑environment Porter мгновенно клонирует актуальную БД через AWS Aurora.
Add‑ons — готовые Helm‑чарты, развёртываемые в один клик в ваш кластер (Datadog Agent, Grafana, Prometheus, ArgoCD, Linkerd).
Deployment targets — “куда деплоить”: связка кластер + namespace + overrides (опционально). Одно application можно развернуть на нескольких deployment targets.
Environment groups — уникальная сущность, которой нет у других платформ. Именованный набор переменных и секретов, единый для нескольких приложений. Например, пять микросервисов используют общие DATABASE_URL и STRIPE_KEY — вы создаёте одну env group, при изменении значения все приложения автоматически передеплоиваются. Плюс синхронизация с cloud‑native secret managers (AWS Secrets Manager, GCP Secret Manager, Azure Key Vault) — паттерн, который команды обычно строят сами через Vault.
Porter.yaml — декларативный манифест в корне репозитория, описывающий весь стек. Аналог app.json + Procfile в одном файле в Heroku; preview‑окружения читают именно этот файл.
Eject — уникальная сущность, которой больше нигде нет. Передумали использовать Porter — нажимаете Eject и получаете чистый Kubernetes‑кластер в своём облаке. Полное отсутствие vendor lock‑in: если Porter повышает цены, закрывается или вы нанимаете свою DevOps‑команду — миграция не нужна, кластер уже у вас. Переезд — это удаление Porter control plane, приложения продолжают работать. Ключевая часть позиционирования и структурный аргумент в пользу BYOC. И эта же фича сознательно ограничивает Porter в добавлении proprietary‑фич, поэтому Porter менее «фичерастый», чем Railway или Vercel.
Окружения и деплойменты
В Porter нет понятия «окружение» — то, что мы называем окружением, собирается из трёх уровней инфраструктуры: отдельные кластеры (полная изоляция, но 200 $ в месяц за каждый), namespace в одном кластере (изоляция через RBAC, шеринг вычислительных мощностей) или просто разные приложения с разными именами. Porter оставляет это решение командам. Гибкость, которая пугает новичков, но даёт свободу зрелым. Промоушен stage → prod устроен иначе, чем у Heroku: единой команды promote нет, переход между deployment targets идёт через GitHub Actions workflow, который Porter автоматически прописывает в репозиторий.
Activity feed различает четыре типа событий: build, pre‑deploy (миграции; если падает — deployment не идёт), deploy (rolling update, zero‑downtime), app (события runtime: OOM, crash loops). Уникальная фича — Blue‑Green Synchronized Deployments. Несколько связанных приложений (фронт и бэк) можно развернуть синхронно — новые версии поднимаются параллельно, трафик переключается одновременно и autoRollback в porter.yaml: если любой сервис не смог задеплоиться, все сервисы автоматически откатываются на последнюю успешную версию.
Porter не прячет ваше облако и ваш Kubernetes
У PaaS вообще есть фундаментальный компромисс: чем больше платформа прячет, тем проще ей пользоваться, но тем быстрее вы упираетесь в ограничения её абстракций. Porter выбирает противоположное — не прятать инфраструктуру, а делать работу с ней удобной.
Вы видите свой VPC, subnets, route tables. Можно настраивать VPC peering, transit gateway, VPN‑подключение к корпоративной сети через стандартные AWS‑средства. Защитные слои перед приложением, такие как AWS Shield, WAF, Cloudflare — включаются в интерфейсе AWS без каких‑либо разрешений со стороны Porter. Можно выбирать конкретные типы EC2-инстансов, GPU‑ноды для AI, спот‑инстансы для воркеров. Можно подключаться с помощью kubectl и делать что угодно: устанавливать любые Helm‑чарты, CRD, operators, custom metrics, network policies. Porter прописывает CI/CD‑пайплайн в ваш репозиторий как GitHub Actions workflow, который вы можете редактировать или перенести в CircleCI, GitLab, Jenkins, — платформа не запирает вас даже в CI. И соответствие нормативам — это ответственность вашего облачного аккаунта: соответствие SOC 2 Type 2 автоматически распространяется на кластер.
Но есть и обратная сторона: kubectl — это еще и риск. Можно удалить control plane, сломать ingress controller, применить конфликтующий Helm‑чарт. Porter доверяет клиенту и не ставит защитных барьеров — это сознательная модель «у вас зрелая команда, имеющая компетенции в области DevOps». Подробнее — в сквозных паттернах.
Отдельная статья о Porter как основном BYOC‑конкуренте ещё впереди — разберу и это, и Terraform‑модули для провижининга, и историю с self‑serve, и Porter Cloud как гибридную модель.
Биллинг
У Porter двойной счёт, в отличие от всех остальных платформ. Платите Porter за управляющий слой (около 10 $ за vCPU в месяц и 5 $ за гигабайт RAM в месяц, минимальный чек — 50 $). Ещё вы платите облачному провайдеру за фактически потреблённые ресурсы: EC2, EBS, NLB, RDS, VPC, egress. Та же логика, что и у Railway BYOC, но у Porter это базовая модель работы, а не enterprise‑опция. Минимальная сумма — около 300 $ в месяц (73 $ за EKS control plane + базовые ноды + NLB + плата за сам Porter). Это отсекает аудиторию, которая хочет «попробовать за 20 $». После начального порога экономика более выгодная: удвоение нагрузки увеличивает счёт на 60–70%, а не на 100%. Главное преимущество — на Porter работают все cloud‑discount‑механизмы (Reserved Instances, Spot Instances, CloudFront, Cloud Credits), которых нет на shared PaaS. Для маленьких команд — Heroku или Railway; для растущих с серьёзной нагрузкой — Porter.
Что видно при сравнении платформ
Прежде чем перейти к выводам, взглянем на сводную таблицу главных сущностей. Терминология везде своя, но роли при этом часто пересекаются.
Роль / слой | Heroku | Vercel | Fly.io | Railway | Porter |
Базовая единица исполнения | Dyno | Serverless function | Machine (Firecracker microVM) | Service | Service внутри application |
Группировка сервисов | Pipeline (несколько app) | Project | App + process groups | Project (нативно) | Application + cluster |
Способ сборки без Dockerfile | Heroku Buildpacks | Framework Presets | Fly.toml (+ Dockerfile) | Railpack | Buildpacks или Dockerfile |
Описание процессов приложения | Procfile | Vercel.json + framework | Fly.toml [processes] | Настройки сервиса (нет файла) | Application service types |
Конфигурация | Config vars | Env vars | Fly.toml secrets | Variables + reference variables | Env vars + environment groups |
«Снимок» прода | Release (slug + vars + addons) | Deployment (иммутабельный) | Machine state | Deployment | Deployment + deployment target |
Persistent storage | Только через add‑on БД | Нет (через Marketplace) | Локальный NVMe (1:1) | Volumes (network) | EBS / RDS / native cloud |
Preview‑окружения | Review apps | Preview deployments | Через snapshot‑fork | PR environments (со всеми сервисами) | PR environments + Aurora Fast Clone |
Marketplace (магазин) | Heroku Elements (несколько сотен) | Vercel Marketplace (партнёры) | Fly Extensions (скромный) | Templates + plugins/databases | Add‑on explorer (Helm‑чарты) |
Уникальная фишка | Release как snapshot всего; задающие стандарт buildpacks/Procfile | Иммутабельный deployment + CDN‑фундамент | Machine как императивный объект + auto‑stop + Fly‑replay + LiteFS | Visual canvas + reference variables | Eject + datastore через native cloud + environment groups |
Роли узнаваемые, реализация и идеология разные. И из этого следуют несколько выводов.
Вывод первый: то, что раньше было различием, сегодня стало общим
Buildpacks, Git‑driven deployment, preview‑окружения, магазин приложений, приватная сеть между сервисами — пятнадцать лет назад каждая из этих фич была отличительной особенностью конкретной платформы. Сегодня это общий фундамент: buildpacks через CNCF ушли в open‑source, Railpack за год подхватили Defang и Dokploy, preview‑окружения есть у всех, Git‑driven deployment фактически стал стандартом.
Вывод второй: управляемые БД — единственный слой, где «за один клик» не получилось ни у кого
Пятнадцать лет развития PaaS — это история о том, как слой за слоем инфраструктура пряталась под абстракцию: серверы → dyno, ручной деплой → git push, VPN → приватная сеть по умолчанию, preview → автоматически на каждый PR. Управляемые БД — единственный слой, где сценарий не сработал ни у кого. Heroku остаётся надёжным решением, но уже не задаёт тренды. Vercel закрыл свой Postgres в декабре 2024 года. Fly.io три года пытался обойтись automated Postgres, партнёрство с Supabase завершилось провалом — и только после этого запустился настоящий MPG. Railway свою управляемую БД так и не сделал. Только Porter пошёл иначе — не пытался делать свой сервис, а сразу через native cloud (RDS, Cloud SQL).
Отмечу главное: если у вас критически важные данные, не полагайтесь на встроенную БД платформы. С самого начала планируйте разделение — виртуальные ресурсы на удобной вам платформе, БД у специализированного провайдера. Удобство одного счёта не окупает риск потерять данные или получить deprecation letter, как случилось с пользователями Vercel Postgres. Всё же поддержка БД — работа отдельной команды с глубокой доменной экспертизой. Никакая кнопка её не заменит.
Вывод третий: философия релиза — выбор культуры
В работе с платформой всё сводится к одному вопросу: релиз — это снимок, который меняется, или иммутабельный артефакт? Heroku и Railway пошли первым путём: изменил config var — конфиг в проде обновился без пересборки. Vercel — вторым: любое изменение требует нового deployment и пересборки. Первый подход даёт операционную гибкость (крутить feature flags без пересборки, быстро реагировать на инциденты), но платит воспроизводимостью — вы никогда точно не знаете, что сейчас в проде и почему. Второй даёт полный аудит и точные откаты, но требует redeploy буквально на каждое изменение — настолько, что Vercel пришлось вынести отдельный платный продукт Edge Config под те сценарии, где пересборка технически не нужна.
Ни один из подходов не может считаться «более правильным» — это выбор рабочей культуры команды. Если у вас маленькая команда, где инциденты нужно закрывать в рабочем чате за 15 минут — вам ближе Heroku‑модель. Если у вас продукт, где каждое изменение проходит через согласования и проверки на соответствие нормативным требованиям — вам ближе Vercel‑модель. И важно этот выбор делать осознанно, а не по инерции из того, «на чём удобнее всего задеплоить MVP».
Сравнивать платформы по фичам почти бесполезно — любая ставит галочку напротив стандартных возможностей. Отличаются они в трёх осях:
Модель биллинга. Heroku тарифицирует зарезервированную мощность, Vercel и Railway — использование, Fly.io — per‑second per‑resource, Porter — двойной счёт (control plane + ваш cloud). Чем модель гибче, тем больше защитных механизмов нужно вокруг неё — общий паттерн отрасли.
Философия релиза. “Снимок, который меняется” (Heroku, Railway) — операционная гибкость: изменил config var, конфиг в проде поменялся без пересборки. “Иммутабельный артефакт” (Vercel) — воспроизводимость и аудит, но редеплой на каждое изменение. Fly.io — императивный контроль над каждой Machine.
Глубина контроля. От «огороженного сада» (Heroku, Vercel, Railway), где джун в первый день не положит прод в принципе, до kubectl‑доступа (Porter) и императивного управления VM (Fly.io). Контроль должен соответствовать зрелости команды: без культуры ревью кода для инфраструктурных изменений kubectl‑доступ — это не гибкость, а ружьё в первом акте.
Приведенное выше — это что реально осталось для выбора. На них и построены шесть вопросов ниже.
Шесть вопросов для выбора платформы
Прежде чем перейти к вопросам давайте определим то, что важно для вашей команды: уровень DevOps‑зрелости и сложность архитектуры. Это не теоретическое позиционирование, а практический выбор.
Vercel — лучший выбор для команд с одним проектом на Next.js, которые не хотят думать об инфраструктуре. Heroku закрывает более сложные сценарии (несколько apps, pipelines, add‑ons), но всё ещё подходит командам без DevOps‑инженера. Railway находится ровно посередине — современный инструмент для full‑stack‑поектов, требующий минимум самостоятельной DevOps‑настройки и предлагающий удобный canvas. Porter и Fly.io требуют DevOps‑зрелости, но решают разные задачи: Porter — когда есть нормативные требования, Fly.io — когда важна география и контроль над VM.
Главное правило: нет абсолютно идеальной платформы — есть лучшая под вашу команду и продукт. Об этом — следующие шесть вопросов.
Где должен жить ваш продакшен?
Если в контуре платформы, то ваш выбор Heroku, Vercel, Railway без BYOC, Fly.io. Если в вашем облачном аккаунте — это Porter, Railway BYOC. Первая развилка, часто определяется нормативными требованиями.
Какая базовая единица соответствует вашему приложению?
Долгоживущий процесс — dyno (Heroku), service (Railway), Machine (Fly.io). Эфемерный обработчик — function (Vercel). Полноценный K8s pod — Porter.
Кто и как часто меняет конфигурацию в production?
Часто, оперативно, без пересборки — Heroku. Редко, через PR и аудит — Vercel. Что‑то посередине — Railway, Porter, Fly.io.
Какой профиль трафика у вашего продукта?
Стабильный — Heroku защищает от сюрпризов роста чека при увеличении посещения сайта. Переменный — Vercel или Railway оказываются эффективнее. Глобальный и с разной плотностью по регионам — Fly.io.
Каков уровень зрелости DevOps‑культуры в вашей команде?
Минимальный — Heroku, Vercel, Railway. Есть базовое понимание K8s и готовность смотреть в AWS Console — Porter. Глубокое понимание VM, регионов, репликации — Fly.io.
Что произойдёт, если платформа закроется или повысит цены вдвое?
Heroku, Vercel или Railway — миграция со всем кодом, данными и архитектурой. Porter с функцией eject — ваш кластер уже у вас, сам Porter можно просто отключить. Fly.io — миграция тоже неизбежна, но к ней проще подготовиться, потому что VM‑модель переносима. Это вопрос долгосрочной независимости, который часто упускают на старте.
Что в итоге происходит на рынке в 2026 году
Heroku остаётся надёжной, зрелой платформой с огромным наследием (buildpacks, Procfile, Twelve‑Factor App стали стандартами), но уже не задаёт тренды, как в 2010‑х. Vercel — в первую очередь платформа под Next.js. Для этого фреймворка — лучший вариант, для всего остального — компромиссный. Fly.io стабилизируется после кризисов и стала заметно дороже после монетизации ранее бесплатных слоёв. Railway растёт как современный Heroku для full‑stack‑команд 2020-х, open‑source Railpack — сигнал, что builder перестаёт быть proprietary‑фичей. Porter эволюционирует в двух направлениях: Porter Cloud — для маленьких команд, Porter BYOC — для растущих компаний, eject между ними — уникальное предложение на рынке. BYOC‑категория в целом сформировалась как полноценный сегмент: помимо Porter, здесь Qovery, Northflank, Flightcontrol, Spectrocloud Palette.
Вопрос для обсуждения
Эта статья показала: архитектура каждой платформы — это слепок эпохи, в которой она родилась. Heroku — Rails 2010-х. Vercel — Jamstack 2018–2020 годов. Fly.io — edge CDN 2017+. Railway — full stack 2020-х. Porter — миграция с Heroku 2020+. Через пять лет появится новая платформа, рождённая текущей эпохой. Может быть, AI‑agent‑first, может быть, что‑то ещё. И выбор тогда снова будет не между «лучше» и «хуже», а вопросом о том, в какой эпохе нам захочется работать следующие пять лет.
А вы как выбирали платформу для текущего продукта? По тому, насколько хорошо она ложится на вашу архитектуру сегодня? Или по тому, насколько хорошо она ляжет на неё через три года? И какой совет вы дали бы себе тогдашнему, если бы могли вернуться?
