Бэкенд для мобильного приложения: зачем приложению сервер, что в нём живёт и сколько он стоит в месяц

Короткий ответ: бэкенд — это сервер, с которым разговаривает приложение. В нём живут API, база данных, вход пользователей, файлы, отправка push и админка для сотрудников. Почти любому приложению для бизнеса он нужен: без него данные не синхронизируются, заказы никуда не уходят, а изменить что-то без новой сборки нельзя. Содержание сервера — отдельная строка бюджета, а не часть цены разработки.

Зачем мобильному приложению сервер?

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

У приложения есть особенности, которых нет у сайта. Сайт обновляется сразу у всех, а приложение — только когда пользователь скачает новую версию. Поэтому многое выносят на сервер нарочно: цены, тексты акций, порядок блоков на главном экране, список городов. Поменяли в админке — увидели все, без проверки в магазинах приложений. Чем больше решений принимает сервер, тем реже нужен новый релиз.

Общее устройство фронтенда, бэкенда и API разобрано в статье «Фронтенд и бэкенд простыми словами». Здесь — только то, что касается приложений.

Что входит в бэкенд приложения?

Обычно восемь частей: API, база данных, авторизация, хранилище файлов, отправка push, админка, фоновые задачи и журналы с резервными копиями. В маленьком приложении часть из них умещается в одну программу на одном сервере, но каждую стоит назвать в ТЗ, чтобы она не выпала из сметы.

Две части заказчики чаще всего забывают. Первая — админка: без неё любое изменение каталога или текста становится задачей программисту. Что в ней должно быть с первого релиза, разобрано в материале об админ-панели. Вторая — отправка push. Уведомление доставляют службы Apple и Google, но решать, кому, когда и что отправить, должен ваш сервер. Он же хранит токены устройств и убирает устаревшие. Как это устроено по шагам — в статье о push-уведомлениях.

Часть	Что делает	Что будет без неё
API	Принимает запросы приложения и отдаёт данные: каталог, заказы, профиль, статусы	Приложение показывает только то, что зашито в сборку
База данных	Хранит пользователей, заказы, записи, историю, настройки	Данные живут на одном телефоне и пропадают при смене устройства
Авторизация	Проверяет вход по телефону, почте или через Яндекс ID и VK ID, выдаёт и отзывает сессии	Нельзя понять, чьи это данные, и отключить украденный аккаунт
Хранилище файлов	Фото, документы, аватары, чеки — отдельно от базы, с ограничением доступа	Файлы раздувают базу или лежат в открытом доступе
Отправка push	Хранит токены устройств и решает, кому и когда отправить уведомление	Push можно разослать только вручную из консоли
Админка	Экран для сотрудников: заказы, пользователи, контент, рассылки	Каждое изменение — задача программисту
Фоновые задачи	Напоминания, обмен с 1С и CRM по расписанию, отчёты, очистка старых данных	Всё, что не происходит по нажатию кнопки, не происходит вовсе
Журналы и копии	Ошибки сервера, резервные копии базы, оповещения о сбоях	О поломке узнаёте из отзывов, а потерянные данные не вернуть

Когда можно обойтись без своего бэкенда?

Когда серверная часть у вас уже есть или приложение не хранит общих данных. В первом случае приложение подключают к API существующего сайта, магазина или CRM. Во втором хватает памяти телефона: калькулятор, справочник, игра без рейтингов, офлайн-каталог, который обновляется вместе со сборкой.

• Уже есть магазин или кабинет с API. Новый сервер не нужен: приложение работает с теми же товарами, заказами и пользователями, что и сайт. Если нужных методов нет, их дописывают в существующую систему, а не заводят вторую базу и синхронизацию между ними.
• Приложение-инструмент. Расчёт, чек-лист, таймер, справочник без входа и без обмена данными с другими людьми.
• Прототип для проверки идеи. Готовый облачный бэкенд позволяет показать работающее приложение инвестору или первым пользователям без своего сервера. Главное — заранее договориться, что для рабочей версии данные переедут.

Если же есть заказы, оплаты, записи, бонусы или переписка, своя серверная часть понадобится. Вопрос только в том, где она будет жить.

Firebase или свой сервер: что выбрать?

Готовый облачный бэкенд быстрее на старте, свой сервер надёжнее для рабочего приложения с клиентами из России. Третий путь — подключиться к API уже работающей у вас системы. Выбор определяют три вещи: есть ли персональные данные, насколько сложна логика и с какими системами нужен обмен.

Firebase и похожие сервисы дают вход, базу, хранение файлов и push почти без серверного кода. Это удобно, но у такого подхода есть цена:

• Логика живёт в рамках сервиса. Простые правила доступа описываются легко, а обмен с 1С, сложные скидки или расчёт графика смен приходится обходить облачными функциями или всё равно поднимать свой сервер рядом.
• Счёт зависит от нагрузки. По описанию тарифов Firebase на бесплатном плане Spark при превышении квоты соответствующий продукт отключается до конца месяца, а на плане Blaze оплата идёт по факту использования. Оповещения о бюджете в Blaze расходы не ограничивают — они только сообщают о них.
• Переезд потом дороже. Структура данных и правила доступа пишутся под конкретный сервис. Перенести их на свой сервер — отдельный проект, а не настройка.

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

Вариант	Плюсы	Минусы	Когда подходит
Готовый облачный бэкенд (например, Firebase)	Вход, база, файлы и push из коробки; быстрый старт без своего сервера	Данные на серверах за рубежом; сложная логика упирается в рамки сервиса; счёт растёт вместе с нагрузкой	Прототип, внутренний тест, приложение без персональных данных граждан России
Свой сервер в российском дата-центре	Данные в России, любая логика и интеграции, предсказуемый счёт за сервер	Сервер нужно обслуживать: обновления, копии, наблюдение	Большинство приложений для бизнеса с клиентами из России
API вашей существующей системы	Нет второй базы: приложение работает с тем же сайтом, CRM или учётной системой	Если у системы нет нужных методов, их придётся дописать; нагрузка от приложения ложится на неё	Магазин, кабинет или CRM уже есть и умеют отдавать данные

Где хранить данные пользователей из России?

На серверах в России. Часть 5 статьи 18 закона 152-ФЗ не допускает запись, хранение и извлечение персональных данных граждан России с использованием баз данных за рубежом при их сборе, в том числе через интернет. Имя, телефон, почта, адрес доставки в приложении — персональные данные, так что база с ними должна стоять в российском дата-центре.

Текст нормы — на consultant.ru (проверено 31 октября 2026). Исключения перечислены в самой норме — пп. 2, 3, 4, 8 ч. 1 ст. 6 закона; подходит ли вам какое-то из них, решает юрист, а не разработчик.

С готовыми облачными бэкендами здесь тонкое место. В списке регионов базы Cloud Firestore российских нет, а регион, выбранный при создании базы, потом изменить нельзя. Практичная схема для рабочего приложения: личные данные, заказы и файлы пользователей — в базе на своём сервере в России, а сервисы платформ используются только для того, без чего не обойтись, например для доставки push. Допустимость такой схемы для вашего случая стоит обсудить с юристом.

Уведомление Роскомнадзора, согласие и политика обработки — та же история, что у сайта; подробно — в статье «Где хранить данные сайта по 152-ФЗ». Что именно заполнять в анкетах App Store и Google Play — отдельная тема, здесь её не повторяем.

Сколько стоит бэкенд в месяц?

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

Ориентир по серверу: по публичным тарифам российских провайдеров небольшой облачный сервер в московском дата-центре обходится примерно в 2–3 тысячи рублей в месяц. Точная цена зависит от провайдера и объёма памяти, тарифы меняются.

• Сервер. Для приложения на старте обычно хватает одного виртуального сервера, где работают API, база и админка; по памяти берут с запасом, от 2 ГБ. Отдельный сервер или управляемая база понадобятся при росте нагрузки.
• Резервные копии. Хранятся отдельно от основного сервера, желательно у другого провайдера или в другом дата-центре. Если в копиях личные данные граждан России, копии тоже лежат в России. Это небольшая, но обязательная статья.
• Хранилище файлов. Если пользователи загружают фото и документы, объём растёт каждый месяц; платить придётся за место и за отдачу файлов.
• Платные сервисы. SMS для входа по коду — заметная статья у приложений с регистрацией по телефону: платите за каждое сообщение. Плюс эквайринг, карты, отправка писем — по тарифам этих сервисов. Способ входа и защиту от лишних кодов стоит выбрать ещё на этапе ТЗ.
• Обслуживание. Обновления системы и библиотек, проверка копий, реакция на сбои, доработки. У нас это поддержка и развитие — от 7 900 ₽ в месяц или разовые задачи.

Что входит в разработку. В тариф мобильного приложения от 200 000 ₽ входит подключение к вашему API или простой бэкенд на нашей стороне. Долгосрочная поддержка серверов, хостинг и платные сторонние сервисы в цену разработки не входят. Сложная бизнес-логика, чаты, карты и большие интеграции оцениваются отдельно. Для ориентира: серверная часть с кабинетами, базой данных и API — это уже объём тарифа веб-приложения, от 160 000 ₽, а связка с 1С, CRM или складом — тарифа интеграций, от 32 000 ₽. Точную смету даём после брифа.

Что должно быть оформлено на заказчика?

Всё, за что платят каждый месяц, и всё, без чего приложение перестанет работать: хостинг, домен, проект для push, платёжные и SMS-сервисы. Разработчик получает к ним доступ как приглашённый пользователь. Тогда смена подрядчика — это смена списка доступов, а не спасение приложения.

1. Аккаунт хостинга на компанию, с вашим договором и вашей оплатой.
2. Домен API — адрес вида api.вашдомен.ru, зарегистрированный на вас. Если сервер переедет, приложение продолжит работать по тому же адресу без нового релиза.
3. Проект для push (Firebase) и ключи отправки APNs из аккаунта разработчика Apple — всё на вас.
4. Платёжный сервис и SMS-шлюз — договоры на компанию, ключи хранятся в настройках сервера, а не в коде.
5. Репозиторий с исходным кодом приложения и сервера. По нашему тарифу исходный код приложения и бэкенда лежит в вашем репозитории, а вы получаете доступы ко всем сервисам и краткую инструкцию по сборке, обновлению и выкладке новых версий.
6. Резервные копии — понимание, где они лежат и как из них восстановиться. Попросите однажды показать восстановление на тестовом сервере.

Аккаунты разработчика Apple и Google Play по тому же правилу оформляются на вас — так записано и в составе нашего тарифа.

Что заложить в бэкенд с первой версии?

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

• Версии API. На телефонах месяцами живут старые сборки. Сервер должен отвечать им по-старому, пока доля таких пользователей не станет незаметной.
• Минимальная версия. Сервер умеет сказать приложению «эта версия больше не поддерживается» и показать экран обновления. Без такого механизма пользователь со старой сборкой остаётся с ошибкой, пока сам не обновится.
• Ограничение запросов. Особенно на отправку SMS-кодов и вход: иначе кто-то сможет запросить тысячи кодов, а платить за SMS придётся вам.
• Работа при плохой связи. Повторная отправка без дублей заказа, понятное сообщение вместо бесконечной загрузки.
• Журнал ошибок и оповещения. Чтобы о сбое сервера узнавал разработчик, а не служба поддержки из отзывов.
• Отдельный тестовый сервер. Новые функции сначала проверяют на нём, а не на живых клиентах.

Какие ошибки встречаются чаще всего?

Чаще всего — серверная часть на аккаунте разработчика, база за рубежом с личными данными клиентов, отсутствие админки и копий. На демонстрации этого не видно, но всплывает оно при смене подрядчика или в первый месяц работы.

• «Сервер мы дадим свой». Удобно на старте, но приложение оказывается привязано к чужому аккаунту и чужой оплате.
• Ключи в коде приложения. Сборку можно разобрать, а ключ от платёжного или SMS-сервиса — использовать. Секреты должны жить только на сервере.
• Прототип стал продуктом. Бэкенд, собранный «на посмотреть» в облачном сервисе, обрастает пользователями, и переезд становится болезненным. Решение о рабочей архитектуре стоит принять до запуска рекламы.
• Нет админки. Каждое изменение акции или цены — новая задача и новый счёт.
• Нет копий или их никто не проверял. Копия, из которой ни разу не восстанавливались, — это надежда, а не страховка.
• В бюджете только разработка. Сервер, SMS и обслуживание выпадают из расчёта, и через месяц приходит неожиданный счёт.

Как это выглядит на реальном проекте?

В приложении знакомств Twin серверная часть написана на Node.js и Express: REST API для анкет и подбора, WebSocket для чата в реальном времени, отправка push и кодов подтверждения на почту. Всё работает в контейнерах Docker за nginx с SSL на Linux-сервере.

Для приложения такого размера схема «одна программа на одном сервере» обычно достаточна на старте, а отдельные серверы добавляют, когда этого перестаёт хватать. У приложения магазина или записи клиентов схема похожая, только вместо подбора анкет — каталог, корзина, расписание и обмен с учётной системой.

По тарифу мобильного приложения после публикации идут 14 дней бесплатной поддержки (мелкие правки). Гарантия по договору — 30 календарных дней с даты акта: ошибки в результате работ по нашей вине, включая серверный код, исправляем бесплатно. Сбои сторонних сервисов — хостинга, SMS, платёжного шлюза — в гарантию не входят. Дальше обслуживание сервера идёт по абонентке или разовыми задачами.

Что подготовить к разговору о бэкенде?

Список данных, которые хранит приложение, список систем, с которыми оно обменивается, и ответ на вопрос «что сотрудники должны менять без программиста». Этого хватает, чтобы выбрать вариант серверной части и честно посчитать ежемесячные расходы.

• Какие данные о пользователях собираем: телефон, почта, адрес, фото, документы.
• Есть ли у вас сайт, магазин, CRM или 1С и умеют ли они отдавать данные по API.
• Что должно происходить без участия пользователя: напоминания, рассылки, выгрузки.
• Сколько пользователей ждёте в первый год — порядок, не точная цифра.
• Кто со стороны компании будет работать в админке и с какими правами.

Короткие ответы на частые вопросы

Что такое бэкенд мобильного приложения?

Это серверная часть, с которой приложение обменивается данными: API, база, вход пользователей, хранилище файлов, отправка push и админка для сотрудников. Пользователь её не видит, но без неё приложение не может показать заказы, синхронизировать данные между устройствами и принимать оплату с проверкой.

Можно ли сделать приложение на Firebase для клиентов из России?

Для прототипа и теста — да. Для рабочего приложения, которое собирает персональные данные граждан России, — с оглядкой на ч. 5 ст. 18 152-ФЗ: в списке регионов базы Firestore нет России, а сменить регион после создания нельзя. Обычно базу с личными данными держат на своём сервере в России; конкретную схему стоит согласовать с юристом.

Сколько стоит содержать сервер приложения в месяц?

Например, по публичным тарифам российских провайдеров небольшой облачный сервер в московском дата-центре обходится примерно в 2–3 тысячи рублей в месяц; точная цена зависит от провайдера и объёма памяти. К этому добавляются домен, SMS, хранилище копий и платные сервисы по их тарифам. Отдельно — работа по обслуживанию: у нас поддержка и развитие от 7 900 ₽ в месяц.

Входит ли бэкенд в цену приложения?

В тариф мобильного приложения от 200 000 ₽ входит подключение к вашему API или простой бэкенд на нашей стороне. Сложная логика, чаты, карты и большие интеграции считаются после брифа, а хостинг и платные сторонние сервисы оплачиваются отдельно.

На кого оформлять сервер и сервисы приложения?

На компанию заказчика: аккаунт хостинга, домен, проект push-уведомлений, платёжный сервис и SMS-шлюз. Разработчику выдаются доступы, а не наоборот, — так приложение не зависит от одного подрядчика.

Услуги и кейсы по теме: мобильные приложения · кейс Twin · цены и сроки