Пока разработчик пишет приложение, оно обычно работает только на его компьютере. Frontend открывается через локальный сервер, Backend доступен по адресу вроде localhost:8000, а база данных находится на той же машине. Для разработки этого достаточно, но другие пользователи такое приложение открыть не смогут.
Следующий этап — развертывание веб-приложения в интернете. Код необходимо запустить на сервере, Frontend сделать доступным из браузера, Backend открыть для запросов, подключить рабочую базу данных и настроить домен. Если приложение использует AI или отдельную ML-модель, нужно также решить, где будет работать эта часть системы.
На этом этапе многие впервые сталкиваются с понятиями deployment, hosting, DNS, HTTPS, environment variables и production. Они могут казаться отдельными сложными технологиями, хотя на практике описывают разные части одной задачи: превратить локальный проект в приложение, которым могут пользоваться другие люди.
Что такое localhost
Во время разработки часто встречаются адреса:
http://localhost:3000
http://localhost:5173
http://localhost:8000
localhost означает текущий компьютер. Когда браузер обращается к такому адресу, запрос не отправляется на удаленный сервер в интернете — он приходит к программе, запущенной на вашей машине. Например: Браузер ↓ localhost:5173 ↓ Frontend Браузер ↓ localhost:8000 ↓ Backend Именно поэтому приложение может отлично работать у разработчика, но ссылка localhost:8000 бесполезна для другого пользователя.
Чтобы открыть проект для внешнего доступа, необходимо выполнить переход с localhost на сервер.
Что значит выложить приложение в интернет
Фраза «выложить сайт» может означать разные вещи. Для статической страницы достаточно разместить HTML, CSS, JavaScript и изображения на подходящем хостинге. Для полноценного веб-приложения задача сложнее. Если проект содержит Frontend, Backend и базу данных, все эти компоненты должны продолжить взаимодействовать после переноса с компьютера разработчика. Упрощенно публикация веб-приложения выглядит так: Пользователь ↓
Интернет ↓ Frontend ↓ Backend ↓ База данных Локальные адреса при этом заменяются публичными адресами, доступными через интернет.
Что такое deployment
Deployment веб-приложения — это процесс подготовки и запуска приложения в среде, где им могут пользоваться реальные пользователи. Deployment может включать загрузку кода, установку зависимостей, настройку переменных окружения, запуск Backend, подключение базы данных, настройку домена и проверку приложения. Важно понимать, что deployment — не просто копирование файлов на сервер.
Локально разработчик контролирует практически все: версию Python, установленные библиотеки, расположение файлов и запущенные процессы. На удаленном сервере эти условия необходимо воспроизвести или явно настроить. Поэтому приложение, которое работает локально, не обязательно автоматически заработает после публикации.
Development и production
Локальная среда, в которой программист пишет и проверяет код, обычно называется development environment. Среда, где работает публичная версия приложения, — production environment. Development и production могут использовать один код, но различаться конфигурацией. Например: Development:
Frontend → localhost:8000
Backend → локальная БД
Production:
Frontend → backend.example.com
Backend → production database
Также могут отличаться секретные ключи, уровень логирования, разрешенные домены и другие параметры. Чем меньше такие значения жестко записаны в исходном коде, тем проще переносить приложение между окружениями.
Где разместить веб-приложение
Для публикации нужен компьютер, который доступен из интернета и способен постоянно выполнять необходимые процессы. В широком смысле это сервер. Сегодня разработчик необязательно арендует физическую машину и самостоятельно настраивает ее с нуля. Существуют облачные платформы, виртуальные серверы и специализированные сервисы для публикации приложений.
Поэтому вопрос где разместить веб-приложение стоит рассматривать через требования проекта. Простому Frontend нужен один набор возможностей, Python Backend — другой, а приложению с тяжелой AI-моделью может понадобиться больше памяти или GPU.
Хостинг для веб-приложения
Термин hosting описывает инфраструктуру, на которой размещается приложение или его часть. Хостинг для веб-приложения должен соответствовать тому, что именно запускает проект. Статические файлы и постоянно работающий серверный процесс — разные задачи. Для Frontend после сборки часто требуется только раздача файлов: index.html styles.css app.js assets/ Backend на Python должен выполнять программу: Python ↓
Backend application ↓ HTTP requests Поэтому один и тот же способ публикации не всегда одинаково удобен для обеих частей.
Развертывание Frontend
Если Frontend состоит из HTML, CSS и JavaScript, после подготовки его файлы можно разместить на сервере или сервисе статического hosting. После этого пользователь получает публичный адрес:
https://example.com
Браузер загружает Frontend по этому адресу и выполняет JavaScript уже на компьютере пользователя. Развертывание Frontend относительно простое, если интерфейс не содержит серверной логики. Основная задача — правильно разместить файлы и настроить адрес Backend, к которому будут отправляться запросы.
Почему localhost остается в опубликованном Frontend
Одна из типичных ошибок выглядит так: fetch("http://localhost:8000/tasks") На компьютере разработчика запрос работает. После публикации Frontend код остается тем же. Но теперь localhost в браузере пользователя означает уже компьютер самого пользователя, а не сервер разработчика. Естественно, Backend на порту 8000 там не запущен. Поэтому адрес Backend в production должен указывать на реальный публичный сервер:
fetch("https://backend.example.com/tasks") В реальных проектах адрес обычно не размножают вручную по десяткам файлов, а выносят в конфигурацию.
Развертывание Backend
Backend нельзя опубликовать так же, как обычный HTML-файл. Серверное приложение должно постоянно работать и принимать запросы. Например, для Python-проекта сервер должен иметь подходящую версию Python, необходимые библиотеки и конфигурацию. Упрощенно развертывание Backend выглядит так: Исходный код ↓ Установка зависимостей ↓ Настройка окружения ↓ Запуск приложения ↓ Публичный адрес
Если процесс Backend остановится, пользователи перестанут получать ответы, даже если Frontend продолжит открываться.
Развертывание Python приложения
При переносе Python-проекта важно явно описать зависимости. Локально библиотека может быть установлена уже несколько месяцев, поэтому разработчик забывает, что приложение от нее зависит. На новом сервере такой библиотеки не будет. Поэтому развертывание Python приложения требует воспроизводимого списка зависимостей и понятного способа запуска проекта.
Кроме библиотек, необходимо проверить версию Python, пути к файлам, подключение к базе и конфигурацию приложения. Именно на deployment часто обнаруживаются скрытые зависимости, которые не были заметны на локальном компьютере.
Как развернуть Backend на Python
Конкретные команды зависят от инфраструктуры, но логика обычно остается похожей. Сервер получает код приложения. Затем устанавливаются зависимости и передаются необходимые настройки. После этого запускается процесс Backend, который слушает определенный порт. Например: Internet ↓ Public server ↓ Python application ↓ Database
Если нужно понять, как развернуть Backend на Python, полезнее сначала разобраться в этой цепочке, а уже затем изучать интерфейс конкретного облачного сервиса.
Порт приложения
Локально Backend часто запускается на 8000, 5000 или другом порту. Порт позволяет операционной системе определить, какому процессу передать входящее соединение. В production инфраструктура может сама назначать приложению внутренний порт. Тогда Backend должен читать его из конфигурации, а не всегда ожидать одно фиксированное значение.
Таким образом, порт Backend приложения является частью серверной конфигурации, а не адресом, который обязательно должен видеть конечный пользователь.
Что такое домен
Публичный сервер может иметь IP-адрес, но пользователям неудобно запоминать последовательность чисел. Домен позволяет использовать понятное имя: example.com или: app.example.com api.example.com Домен для веб-приложения связывает удобное человеку имя с инфраструктурой, где работает проект. Само приложение может функционировать и без красивого домена, но для полноценного продукта собственный адрес значительно удобнее.
Что такое DNS
DNS помогает браузеру понять, куда отправить запрос для конкретного доменного имени. Упрощенно: example.com ↓ DNS ↓ IP сервера ↓ Приложение После покупки или получения домена необходимо настроить DNS-записи так, чтобы они указывали на нужную инфраструктуру. Поэтому настройка DNS для сайта является связующим этапом между доменом и сервером.
Изменения DNS могут применяться не мгновенно, что иногда вызывает путаницу при первой публикации проекта.
Что такое HTTPS
Обычный HTTP передает данные без той защиты канала, которую предоставляет HTTPS. HTTPS использует TLS для шифрования соединения между браузером и сервером. Это особенно важно при передаче паролей, токенов и другой чувствительной информации. Публичное приложение обычно должно работать через:
https://example.com
а не:
http://example.com
Поэтому HTTPS для веб-приложения — стандартная часть production-конфигурации, а не дополнительная функция только для крупных сайтов.
SSL-сертификат для сайта
Для установки защищенного соединения сервер использует цифровой сертификат. В разговорной речи часто говорят SSL-сертификат, хотя современные соединения используют TLS. SSL-сертификат для сайта подтверждает домен и позволяет браузеру установить защищенное соединение.
Многие современные hosting-платформы могут выпускать и обновлять сертификаты автоматически. При самостоятельном управлении сервером настройкой необходимо заниматься отдельно.
Как Frontend подключается к Backend после deployment
Локально архитектура могла выглядеть так: Frontend:
http://localhost:5173
Backend:
http://localhost:8000
После публикации: Frontend:
https://example.com
Backend:
https://api.example.com
Frontend должен отправлять запросы на новый адрес. Именно подключение Frontend к Backend после deployment часто становится источником первых production-ошибок. Код работает, интерфейс открывается, но данные не загружаются, потому что запросы продолжают уходить на старый адрес или блокируются настройками безопасности.
CORS после deployment
Если Frontend и Backend находятся на разных origin, браузер применяет правила CORS. Например: Frontend:
https://example.com
Backend:
https://api.example.com
Backend должен разрешать запросы от нужного Frontend-домена. При разработке разработчик мог разрешить localhost, но после публикации появляется новый адрес. Поэтому настройка CORS в production должна учитывать реальные домены приложения. Разрешать любые источники без необходимости тоже не стоит.
База данных в production
Локально база может находиться на компьютере разработчика. После deployment серверу нужна база, доступная из production-среды. Она может работать на той же инфраструктуре или быть отдельным управляемым сервисом. База данных в production должна иметь собственную конфигурацию подключения, учетные данные и правила доступа. Важно не переносить в публичную среду привычку хранить пароль от БД прямо в исходном коде.
Подключение Backend к базе данных на сервере
Локально строка подключения может указывать на: localhost После публикации расположение базы меняется. Backend получает новый адрес, имя базы, пользователя, пароль и другие параметры. Поэтому подключение Backend к базе данных в production обычно настраивается через переменные окружения или другой механизм конфигурации.
Код приложения при этом может остаться практически тем же. Меняются параметры среды, в которой он работает.
Переменные окружения в production
Представим такой код: DATABASE_PASSWORD = "my-secret-password" Если проект загружен в публичный репозиторий, пароль оказывается вместе с исходным кодом. Вместо этого конфиденциальные и зависящие от окружения значения выносят из кода. Переменные окружения в production могут содержать строку подключения к БД, секретные ключи, адреса внешних сервисов и другие настройки. Приложение получает их во время запуска.
Это позволяет использовать один код в разных средах:
Development → свои настройки
Production → свои настройки
Секретные ключи приложения
Пароли от базы, приватные токены и ключи сторонних сервисов нельзя размещать в клиентском JavaScript или публиковать в репозитории. Такие значения должны оставаться на серверной стороне. Хранение секретных ключей особенно важно для приложений, использующих внешние AI-сервисы, платежные системы, email-провайдеров и другие платные или приватные интеграции.
Если ключ попал в публичный репозиторий, одного удаления строки из последнего commit может быть недостаточно. Такой секрет обычно следует считать скомпрометированным и заменить.
Конфигурация development и production
Часть параметров приложения закономерно различается между средами. Например: Development: DEBUG=true BACKEND_URL=http://localhost:8000 Production: DEBUG=false BACKEND_URL=https://api.example.com Конфигурация development и production помогает не изменять исходный код вручную перед каждой публикацией.
Чем лучше настройки отделены от логики приложения, тем меньше вероятность случайно запустить production с локальными адресами или тестовыми параметрами.
Как публиковать изменения приложения
После первого deployment разработка не заканчивается. Появляются новые функции, исправления и изменения интерфейса. Обычно разработчик изменяет код локально, тестирует его и затем публикует новую версию. Обновление веб-приложения на сервере должно происходить предсказуемо. Если каждый deployment выполняется случайным набором ручных действий, со временем становится трудно понять, какая версия кода сейчас работает.
Поэтому полезно постепенно автоматизировать сборку, проверки и публикацию.
Что такое CI/CD
CI/CD — набор практик автоматизации проверки и доставки изменений. Например: Изменение кода ↓ Автоматические тесты ↓ Сборка ↓ Deployment Для первого проекта сложная инфраструктура CI/CD необязательна. Однако понимание идеи помогает увидеть, как профессиональные команды уменьшают количество ручных операций.
CI/CD для веб-приложения становится особенно полезным, когда обновления выходят регулярно или над одним проектом работает несколько разработчиков.
Логи приложения на сервере
Локально ошибка сразу появляется в терминале разработчика. В production пользователь может столкнуться с проблемой в момент, когда программист вообще не смотрит на сервер. Поэтому необходимо сохранять информацию о работе приложения. Логи веб-приложения помогают увидеть ошибки, время запросов, проблемы подключения к БД и другие события.
Например, вместо сообщения пользователя «кнопка не работает» разработчик может найти конкретную серверную ошибку и понять, где она возникла.
Почему приложение работает локально, но не на сервере
Это одна из самых распространенных ситуаций после первого deployment. Причины могут быть разными: отсутствует библиотека, неправильно указан путь к файлу, нет переменной окружения, сервер использует другую версию Python, база недоступна или Frontend обращается к localhost.
Поэтому запрос почему приложение работает локально но не на сервере не имеет одного универсального ответа. Нужно сравнивать окружения и последовательно проверять цепочку приложения. Полезно начать с логов Backend, затем проверить конфигурацию, сеть, базу данных и запросы браузера.
Ошибки deployment веб-приложения
Одна из частых проблем — отсутствие зависимости на сервере. Другая — неправильные переменные окружения. Также встречаются неправильные домены в CORS, локальные адреса в Frontend, отсутствие доступа к базе, неверный порт и проблемы с файловыми путями. Ошибки deployment веб-приложения удобнее искать по слоям: Открывается ли Frontend? ↓ Доходит ли запрос до Backend? ↓ Работает ли Backend? ↓ Доступна ли база? ↓
Работают ли внешние сервисы? Такой подход намного эффективнее случайного изменения настроек.
Как проверить Backend после deployment
Первое, что нужно выяснить, — запущен ли сервер вообще. Если Backend предоставляет простой проверочный маршрут, можно отправить запрос и убедиться, что процесс отвечает. Например: GET /health Ответ: { "status": "ok" } Проверка Backend после deployment позволяет отделить проблему серверного процесса от проблем Frontend или конкретной бизнес-логики.
После этого можно тестировать маршруты, которые обращаются к базе и другим сервисам.
Health check приложения
Health check — простая проверка того, что приложение запущено и способно отвечать. Например: /health может возвращать 200 OK, если сервер работает. Более сложные проверки могут учитывать доступность базы или других критических компонентов. Health check приложения полезен не только разработчику. Облачная инфраструктура также может использовать его, чтобы определить состояние запущенного сервиса.
Как проверить Frontend после публикации
Если страница открывается, это еще не означает, что приложение работает полностью. Нужно проверить запросы к Backend, загрузку данных, отправку форм, авторизацию и обработку ошибок. Для этого полезен раздел Network в инструментах разработчика браузера. Он показывает адрес запроса, HTTP-метод, статус и ответ сервера. Проверка Frontend после deployment особенно важна после изменения домена Backend или CORS.
Развертывание приложения с базой данных
Когда проект использует постоянное хранилище, deployment состоит минимум из двух связанных частей: приложения и базы. Нужно убедиться, что Backend может подключиться к production database и что структура таблиц соответствует версии кода. Если проект использует миграции, они должны быть применены к рабочей базе.
Поэтому развертывание приложения с базой данных требует более аккуратного процесса, чем публикация статической страницы. Особенно важно не перепутать локальную тестовую базу с production и не удалить пользовательские данные во время обновления.
Миграции базы данных при deployment
Представим, что новая версия Backend ожидает столбец avatar_url, которого еще нет в production database. Код будет обращаться к полю, а база не сможет выполнить запрос. Поэтому изменение модели данных и публикация новой версии приложения должны быть согласованы. Миграции базы данных при deployment позволяют обновить структуру БД до состояния, которое ожидает новая версия Backend.
Чем больше становится продукт, тем важнее контролировать такие изменения.
Резервное копирование базы данных
Код приложения обычно можно восстановить из системы контроля версий. Пользовательские данные восстановить намного сложнее, если их единственная копия была удалена. Поэтому для реального приложения нужно продумать резервное копирование базы данных.
Частота и схема резервного копирования зависят от ценности и скорости изменения информации. Для учебного демо требования могут быть минимальными, а для коммерческого продукта потеря нескольких часов данных уже может быть серьезной проблемой. Backup особенно важен перед потенциально опасными миграциями и крупными изменениями инфраструктуры.
Как развернуть приложение с AI-моделью
AI добавляет еще один компонент. Самый простой вариант: Frontend ↓ Backend ↓ ML-модель ↓ Database Если модель находится внутри Backend, на сервер необходимо перенести ее файл и все библиотеки, необходимые для inference. В более сложной архитектуре: Frontend ↓ Backend ├── Database ↓ AI-service ↓ Model
Развертывание приложения с AI-моделью требует учитывать размер модели, потребление памяти, время inference и необходимые вычислительные ресурсы.
Где запускать ML-модель
Небольшая модель может работать на CPU вместе с серверным приложением. Более тяжелые модели могут требовать отдельного сервиса или GPU. Поэтому вопрос где запускать ML-модель нельзя решать только по названию алгоритма. Нужно измерять реальные требования.
Если модель занимает немного памяти и отвечает за десятки миллисекунд, отдельная сложная инфраструктура может быть избыточной. Если один prediction требует значительных ресурсов, архитектура будет другой. Для первого проекта разумно начинать с наиболее простой схемы, которая удовлетворяет требованиям.
Файлы в production
Локально приложение может сохранять загруженное изображение в папку: uploads/ На некоторых типах облачной инфраструктуры локальная файловая система может быть временной или изменяться при перезапуске экземпляра. Поэтому хранение файлов в production нужно проектировать отдельно.
Для постоянных пользовательских изображений и документов часто используют специализированное объектное хранилище, а в базе сохраняют ссылку и метаданные. Это особенно важно для приложений, принимающих фотографии для обработки AI-моделью.
Статический Frontend и отдельный Backend
Frontend и Backend необязательно должны находиться на одном сервере. Например: Frontend hosting
https://example.com
↓ Backend server
https://api.example.com
↓ Database Такое разделение Frontend и Backend при deployment позволяет независимо обновлять и масштабировать части приложения. Но для небольшого проекта это не обязательное требование. Иногда проще сначала развернуть систему минимальным количеством компонентов.
Нужно ли использовать Docker
Docker помогает упаковать приложение вместе с его окружением и сделать запуск более воспроизводимым. Но Docker для deployment веб-приложения не является обязательным условием первой публикации. Если hosting-платформа уже умеет устанавливать зависимости и запускать Python-проект, дополнительный контейнер может не дать новичку немедленной пользы.
Docker становится особенно удобным, когда необходимо одинаково запускать несколько сервисов или обеспечить предсказуемое окружение на разных машинах.
Как подготовить приложение к deployment
Перед публикацией полезно проверить проект локально в условиях, максимально похожих на production. Убедитесь, что зависимости описаны, секреты вынесены из кода, адрес Backend задается через конфигурацию, а приложение не зависит от случайных файлов на вашем компьютере. Также необходимо проверить обработку ошибок и понять, где будут находиться логи.
Таким образом, подготовка приложения к deployment начинается еще до загрузки проекта на сервер.
Чек-лист deployment веб-приложения
Перед первой публикацией полезно пройти последовательную проверку. У приложения должен быть воспроизводимый способ запуска. Все необходимые зависимости должны быть описаны. Секреты и пароли не должны находиться в публичном исходном коде. Frontend должен знать production-адрес Backend. Backend должен иметь доступ к production database. Домены и CORS должны соответствовать реальной конфигурации.
После запуска нужно проверить HTTPS, основные пользовательские сценарии, логи и сохранение данных. Такой чек-лист deployment веб-приложения уменьшает вероятность ситуации, когда каждая ошибка обнаруживается только после предыдущей.
Как выложить веб-приложение в интернет: последовательность действий
Если собрать процесс в одну схему, получится примерно следующий порядок. Сначала приложение должно стабильно работать локально. Затем необходимо определить, какие компоненты нужно разместить: Frontend, Backend, database, файлы и, при необходимости, AI-модель.
После этого выбирается инфраструктура, настраиваются production-переменные, разворачивается база и запускается Backend. Затем публикуется Frontend и указывается правильный адрес сервера. Следующий этап — домен, DNS и HTTPS. После публикации проверяются запросы, база, пользовательские сценарии и логи.
То есть ответ на вопрос как выложить веб-приложение в интернет — это не одна команда, а перенос всей рабочей цепочки из development в production.
От localhost до production
Полезно воспринимать deployment как последовательную трансформацию адресов и окружения. Было: Browser ↓ localhost Frontend ↓ localhost Backend ↓ local database Стало: User ↓
https://example.com
↓
https://api.example.com
↓ production database При этом логика приложения может практически не измениться. Основная задача перехода от localhost до production — правильно перенести окружение, конфигурацию и инфраструктурные зависимости проекта.
Нужно ли сразу строить сложную инфраструктуру
Нет. Первый небольшой проект необязательно начинать с Kubernetes, нескольких серверов, балансировщиков и десятка микросервисов. Если приложение обслуживает небольшое количество пользователей, простая инфраструктура часто лучше. Ее легче понимать, тестировать и исправлять.
Усложнение должно появляться после конкретной проблемы: недостатка производительности, требований к надежности или необходимости независимо масштабировать компоненты. Это особенно важно для начинающего разработчика: цель первого deployment — понять весь путь приложения до пользователя, а не воспроизвести инфраструктуру крупной технологической компании.
Что делать после первого deployment
После публикации начинается другой этап разработки. Теперь ошибки могут происходить не только на компьютере разработчика, а в реальной среде. Нужно следить за логами, исправлять проблемы, обновлять зависимости, проверять базу и выпускать новые версии.
Также полезно наблюдать, какие функции действительно используют люди. Это помогает отличить технически работающий проект от продукта, который приносит пользователю пользу. Поэтому deployment — не финальная точка разработки, а переход к эксплуатации приложения.
Частые ошибки начинающих при публикации приложения
Одна из самых распространенных ошибок — оставить localhost в production Frontend. Вторая — записать пароль или секретный ключ прямо в репозиторий. Третья — проверить только главную страницу и не протестировать реальные запросы к Backend. Четвертая — забыть применить миграции базы. Пятая — не смотреть серверные логи и пытаться угадывать причину ошибки только по интерфейсу.
Еще одна проблема — преждевременное усложнение. Если приложение состоит из нескольких страниц и одного Backend, необязательно сразу строить распределенную инфраструктуру. Хороший первый deployment должен быть настолько простым, насколько позволяет задача.
FAQ
localhost указывает на текущий компьютер. Публичный сервер доступен через сеть и может принимать запросы пользователей из интернета. Да. Если сайт состоит из статических файлов или работает только с внешними сервисами, отдельный собственный Backend может быть не нужен. Да. Это распространенная схема. В таком случае необходимо правильно настроить адрес Backend, HTTPS и CORS.
Не всегда. Многие hosting-сервисы предоставляют технический адрес. Собственный домен становится полезным, когда проект нужно показывать пользователям как полноценный продукт. Причиной могут быть отсутствующие зависимости, неправильные переменные окружения, порт, доступ к базе, файловые пути или другие различия между development и production.
Она должна быть доступна Backend из production-среды. Это может быть отдельный database service или база на управляемой инфраструктуре. Главное — обеспечить корректное подключение, безопасность и сохранность данных. Нет. Docker полезен, но не является обязательным условием публикации. Сначала важнее понять сам процесс запуска приложения на сервере.
Не обязательно. Можно использовать облачную платформу или hosting, который предоставляет необходимую инфраструктуру как сервис. Открытие Frontend, ответы Backend, работу базы, отправку форм, авторизацию, загрузку файлов, HTTPS и серверные логи. Для AI-приложения дополнительно нужно проверить inference модели.
Заключение
Переход от локального проекта к публичному приложению — важный этап развития разработчика. Именно здесь отдельные знания о Frontend, Backend, базах данных и сетевых запросах начинают складываться в единую работающую систему.
Для первого deployment не нужна максимально сложная инфраструктура. Нужно добиться более практичной цели: пользователь открывает публичный адрес, интерфейс загружается, запрос доходит до Backend, сервер работает с базой или AI-моделью и возвращает корректный результат. После этого проект перестает существовать только на компьютере разработчика. Он становится настоящим веб-приложением, доступным другим людям.