Что выбрать
Альтернатива Yandex Cloud Serverless для небольшого проекта
Коротко
Альтернатива Yandex Cloud Serverless имеет смысл, когда проект один и весь слой из учётных записей, сетей и реестра образов вам не нужен. Большие облака, как правило, рассчитаны на команды и на набор связанных между собой сервисов, поэтому до первого запуска приходится пройти длинную настройку. Netrun решает более узкую задачу: вы загружаете код или репозиторий с GitHub, платформа сама определяет язык, собирает проект и выдаёт публичную ссылку с HTTPS, а плата идёт за тариф, а не по потреблению. Если проекту нужны управляемые базы, объектное хранилище и разграничение прав между людьми, честнее остаться в большом облаке.
Обычно путь в большое облако выглядит так: завести организацию и каталог, разобраться с учётными записями и правами доступа, настроить сеть, собрать образ приложения и положить его в реестр — и только после этого создать контейнер, который начнёт отвечать по ссылке. Так, как правило, устроены облака корпоративного уровня, и это не претензия: они рассчитаны на команды, роли и десяток связанных между собой сервисов. Альтернатива Yandex Cloud Serverless нужна не потому, что там что-то плохо, а потому, что одному проекту весь этот слой не нужен.
В Netrun его нет: вы загружаете папку с кодом или репозиторий с GitHub, платформа сама определяет язык, собирает проект и выдаёт публичную ссылку с HTTPS. Образ собирать и никуда класть не нужно, а платите вы за тариф, а не по потреблению. Дальше — честное сравнение подходов: когда аналог большого облака вам вообще не нужен, а когда, наоборот, лучше остаться в нём.
Посчитайте, сколько человек будет работать с проектом#
Учётные записи, роли и права доступа в больших облаках обычно нужны там, где к инфраструктуре подходят несколько человек и есть требования по безопасности. Если проект личный и трогаете его только вы, этот слой превращается в настройку, которую надо пройти до первого запуска. В Netrun отдельных сервисных аккаунтов и ролей нет: есть ваш кабинет и проекты в нём.
Проверьте, нужны ли вам управляемые сервисы#
Большие облака, как правило, сильны тем, что рядом с приложением можно взять готовую базу данных, объектное хранилище или очереди и не обслуживать их самому. В Netrun этого нет: управляемой базы как отдельной услуги, объектного хранилища и CDN у нас не бывает. База поднимается своим сервисом рядом с приложением через docker-compose либо берётся внешняя. Если такие сервисы — опора вашего проекта, честнее остаться в большом облаке.
Сравните путь от кода до рабочей ссылки#
Serverless-контейнеры, как правило, принимают не исходный код, а собранный заранее образ: значит, нужен свой Dockerfile, сборка и реестр, куда этот образ кладут, и всё это повторяется при каждом изменении. Netrun принимает сам код — ZIP-архив или репозиторий с GitHub, в том числе приватный. Язык и тип проекта определяются по файлам, сборка идёт на нашей стороне. Если Dockerfile у вас уже написан, мы возьмём его, но заводить его специально ради публикации не придётся.
Решите, какая модель оплаты вам удобнее#
Оплата в больших облаках обычно устроена по потреблению: каждый ресурс считается отдельно, и счёт складывается из этих счётчиков. Это удобно, когда нагрузка скачет и не хочется платить за простой, но итоговую сумму приходится прикидывать самому. В Netrun вы выбираете тариф и знаете плату заранее, независимо от того, сколько людей открыло ссылку. Актуальные цены и лимиты видны в кабинете.
Перенесите код и уберите привязки к облаку#
Возьмите исходники, файл зависимостей (requirements.txt, package.json, go.mod) и список секретов — токены, ключи, строку подключения. Не кладите в архив node_modules, venv и другие папки с зависимостями: они ставятся при сборке. Веб-приложение должно слушать порт из переменной окружения PORT и адрес 0.0.0.0, а не фиксированный порт — это причина номер один, почему ссылка не открывается. Если приложение писало файлы в объектное хранилище облака, переключите его на постоянную папку /data или на внешний сервис.
Проверьте, что после переезда всё на месте#
После публикации откройте ссылку и посмотрите логи в кабинете — они идут в реальном времени, поэтому ошибку при старте видно сразу, а не по пустой странице. Убедитесь, что секреты подставились и приложение читает их как переменные окружения, а данные, которые должны пережить обновление кода, лежат в папке /data. Домен, который раньше указывал на облако, привязывается на тарифе Pro во вкладке «Домены».
Универсального ответа нет, и выбор честно делится по размеру задачи. Большое облако стоит брать, когда над проектом работает команда, есть требования по доступам и безопасности, а рядом нужны управляемые базы и хранилище — для этого оно и сделано, и менять его на платформу попроще смысла нет. Если же это один проект и вам нужно пройти путь от кода до рабочей ссылки, слой из ролей, сетей и реестра образов окажется работой ради работы: загрузите код в Netrun и получите адрес с HTTPS, а плата будет за тариф, а не по счётчикам. Попробовать Netrun.
Частые вопросы
Что выбрать, если проект пока один, но может вырасти?
Начните с того, что быстрее даёт результат, — с платформы, где достаточно загрузить код. Перенести проект в большое облако позже несложно: код остаётся вашим, а Dockerfile, если он у вас появится, работает и там, и там. Переезжать имеет смысл тогда, когда появятся команда, требования по доступам или управляемые сервисы, а не заранее.
Можно ли перенести проект из Яндекс Облака без правок в коде?
Чаще всего да, если приложение читает настройки из переменных окружения и слушает порт из переменной PORT. Править придётся то, что завязано на сами сервисы облака: обращения к объектному хранилищу, к управляемой базе или к внутренним адресам сети. Всё остальное — обычный код, который просто запускается в другом месте.
Что делать с базой данных при переезде?
Путей два. Можно поднять базу своим сервисом рядом с приложением: по вашему docker-compose Netrun запустит до пяти связанных сервисов в одном проекте, а данные будут жить в именованном томе из вашего файла. Можно оставить внешнюю базу и передать строку подключения секретом — тогда приложение продолжит ходить туда же, куда ходило раньше.
Есть ли в Netrun объектное хранилище и управляемые сервисы?
Нет. Отдельного объектного хранилища, CDN и управляемых баз как услуги у нас не бывает — это как раз то, ради чего берут полноценное облако. Файлы, которые пишет приложение, хранятся в постоянной папке /data: она переживает обновление кода и перезапуск, а список файлов виден в кабинете. У проектов со своим docker-compose эту роль играет именованный том из вашего файла, а для большого объёма медиа лучше подключить внешний сервис.
Изменится ли плата, если на сайт придёт много людей?
Нет, тариф фиксированный: плата не зависит от числа открытых страниц и объёма трафика. Ограничения тарифа касаются ресурсов самого проекта, актуальные значения видны в кабинете. Это и есть главное отличие от оплаты по потреблению, где счёт складывается из счётчиков за время работы, память и трафик.
Останется ли у проекта свой домен?
Да, на тарифе Pro. Домен, который раньше указывал на облако, привязывается во вкладке «Домены»: указываете домен, добавляете DNS-запись по подсказке и нажимаете «Проверить». Доменов на один сайт можно привязать сколько угодно, каждый со своим HTTPS. Боту и фоновому скрипту домен не нужен — они не отвечают по ссылке.
Что такое Netrun?
Netrun — облачная платформа, которая запускает ваш код в интернете. Вы загружаете проект, отвечаете на пару вопросов и получаете рабочую ссылку. Серверы, Docker, nginx, домен и SSL мы берём на себя.
Нужно ли уметь работать с Docker?
Нет. Netrun сам определяет язык проекта и собирает его. Если у вас уже есть Dockerfile или docker-compose, мы их поддержим, но писать их специально не требуется.
Какие языки и технологии поддерживаются?
Python, Node.js, Go, Rust, Ruby, PHP, Java, .NET, Deno, Bun, Elixir, статические сайты и bash-скрипты. Можно принести свой Dockerfile или docker-compose, но чаще стек определяется по коду автоматически.
За что списываются деньги?
С баланса оплачиваются тариф и дополнительные слоты. Бесплатный тариф денег не требует.