Як експортувати застосунок, створений з ШІ, і розгорнути його на власному сервері

Щоб розгорнути застосунок, створений з ШІ, на власному сервері, витягніть код (завантаженням або синхронізацією з репозиторієм GitHub, який належить вам), перетворіть його секрети на змінні середовища, перенесіть або відтворіть базу даних і розгорніть на хості, що відповідає типу застосунку: статичний хостинг для простого фронтенду або платформу, яка запускає сервери чи контейнери, для всього, що має бекенд. Код — зазвичай найпростіша частина. Дані, секрети та сервіси, які конструктор тихо запускав для вас, — ось де справжня робота.

Навіщо взагалі експортувати

Є вагомі причини забрати свій код із собою, а є менш вагомі.

Вагомі причини:

• Володіння і страхування. Копія коду у вашому власному репозиторії захищає вас, якщо конструктор змінить ціни, функції або умови.
• Передача розробникам. Інженерна команда захоче мати код у Git, в інструментах і процесі рев'ю, які вони вже використовують.
• Конкретні вимоги. Місце зберігання даних, певний хмарний провайдер, корпоративні політики безпеки або інфраструктура, якої не пропонує конструктор.
• Масштаб або вартість на рівні, коли власна інфраструктура справді окупається.

Менш вагомі причини: переносити невеликий застосунок з кількома користувачами, щоб заощадити невелику суму щомісяця. Власний хостинг перекладає роботу на вас: оновлення, резервні копії, моніторинг, виправлення безпеки. Це може бути правильним вибором, просто зробіть його свідомо.

Розумний компроміс: продовжуйте створювати й розміщувати застосунок там, де він є, але синхронізуйте з власним репозиторієм GitHub з самого початку. Ви отримуєте страховку без операційної роботи. Якщо Git для вас новий, прочитайте що таке GitHub.

Що містить експорт, а чого не містить

Перш ніж покладатися на експорт, відкрийте його й перевірте. Зазвичай:

Секрети навмисно не включають: архів, який ви можете надіслати емейлом або закомітити, ніколи не повинен містити живі ключі. Залежності не включають, бо їх відновлюють з lock-файлу.

Крок 1: Вивантажте код

Два поширені способи:

• Завантажити архів проєкту. Це швидко і підходить для одноразового переносу або резервної копії.
• Синхронізувати з GitHub. Краще для всього, що триває: повна історія, легко клонувати куди завгодно, і більшість хостингів розгортають напряму з репозиторію GitHub при кожному push.

У будь-якому разі клонуйте або розпакуйте проєкт на комп'ютері (або в хмарному середовищі розробки) і шукайте README. Якщо його немає, попросіть ШІ в конструкторі написати його, перш ніж ви підете:

Напиши README для запуску цього проєкту поза цією платформою: стек, потрібні версії середовища виконання, команди встановлення і збірки, команда запуску та порт, кожна змінна середовища, яку читає код (назви і призначення, без значень), а також як запускаються міграції бази даних.

Цей один запит заощадить години, бо змусить записати неявні частини налаштування.

Крок 2: Спершу запустіть локально

Перш ніж розгортати будь-де, переконайтеся, що застосунок працює сам по собі:

1. Встановіть середовище виконання, яке називає README, — Node.js, Python, Java, .NET — потрібної версії.
2. Встановіть залежності (npm install, pnpm install, pip install -r requirements.txt або еквівалент).
3. Створіть локальний файл .env зі змінними середовища, де це можливо, з тестовими ключами. Тримайте його поза Git. Що таке змінні середовища і секрети пояснює цю ідею.
4. Підключіть базу даних — локальний Postgres або безкоштовну базу для розробки від керованого провайдера.
5. Запустіть міграції, потім стартуйте застосунок і пройдіться основними сценаріями.

Усе, що ламається тут, зламається і на хості, і налагоджувати це набагато простіше на власному комп'ютері. Поширені несподіванки: жорстко прописана URL превью конструктора, відсутня змінна середовища, яку конструктор вставляв автоматично, або сервіс (файлове сховище, зміна розміру зображень), який існував лише на платформі.

Крок 3: Перенесіть дані

Якщо в застосунку є справжні користувачі, дані важать більше за код.

• Експортуйте базу даних. Для Postgres pg_dump створює файл, який можна відновити через pg_restore або psql у нову базу. Попросіть ШІ конструктора виконати це, якщо немає прямого доступу, і пояснити, що саме вийшло.
• Перенесіть завантажені файли. Якщо користувачі завантажували зображення чи документи, вони зберігаються в об'єктному сховищі окремо від бази даних. Скопіюйте їх у нове сховище (наприклад, S3-сумісний бакет) і оновіть збережені URL, якщо вони містять старий хост.
• Сплануйте перемикання. Для живого застосунку простий підхід — коротке вікно обслуговування: зупиніть запис, зробіть фінальний експорт, відновіть його на новому хості, перемкніть DNS і знову відкрийте доступ. Запишіть кожен крок заздалегідь.
• Протестуйте відновлення в тимчасовій базі даних перед справжнім переносом.

Якщо Postgres для вас незнайомий, що таке Postgres пояснює основи.

Крок 4: Оберіть, де розмістити застосунок

Підберіть хост під те, яким є застосунок. Назви нижче — приклади відомих провайдерів у кожній категорії станом на вересень 2026 року, а не рейтинг; перевіряйте актуальні функції та ціни на їхніх сайтах.

Вам також знадобиться:

• Керована база даних. Багато хостів застосунків пропонують Postgres, а окремі сервіси, як Neon чи Supabase, надають його самостійно. Керована база варта того: резервні копії й оновлення — не ваша турбота.
• Об'єктне сховище для завантажень, якщо вони є в застосунку.
• Надсилання email, платежі та провайдери ШІ — зазвичай їм достатньо тих самих ключів API на новому хості.

Чесно про компроміси: платформні хости (перші чотири рядки) швидше налаштувати й підтримувати, але контролю менше, а витрати можуть зростати разом із трафіком. Віртуальний сервер часто дешевший при сталому навантаженні і повністю під вашим контролем, але ви відповідаєте за оновлення, TLS, резервні копії, моніторинг і відновлення. Якщо в команді ніхто не хоче цієї роботи, обирайте платформу. Основи того, що входить до хостингу, — у що таке веб-хостинг.

Крок 5: Розгорніть і перемкніться

1. Підключіть репозиторій до хоста або завантажте образ контейнера.
2. Задайте змінні середовища в панелі хоста — кожну з README, з живими значеннями.
3. Задайте команди збірки і запуску та порт. Багато хостів передають порт через змінну PORT; застосунок має слухати на ньому й на всіх інтерфейсах (0.0.0.0), а не лише на localhost.
4. Запустіть міграції на новій базі даних.
5. Протестуйте на тимчасовій URL хоста перед тим, як чіпати DNS.
6. Оновіть зовнішні сервіси, які вказують на стару URL: вебхуки платежів, URL перенаправлення OAuth для входу, посилання в email, дозволені origin.
7. Перенесіть домен, оновивши записи DNS на новий хост. Як підключити власний домен пояснює записи.
8. Залиште стару версію працювати ще трохи, доки не будете впевнені, а потім вимкніть її.

Крок 6 найчастіше забувають: входи й платежі, які тихо ламаються після переносу, зазвичай пов'язані з URL зворотного виклику, який досі вказує на старий хост.

Крок 6: Візьміть на себе експлуатацію

Коли ви розгортаєте застосунок самі, те, чим раніше займався конструктор, стає вашим. Щонайменше: автоматичні резервні копії бази даних з перевіреним відновленням, відстеження помилок, сповіщення про доступність, оновлення залежностей і список того, хто має доступ до кожного облікового запису. Як перевести прототип з ШІ у продакшн докладніше розбирає цей список.

Чекліст експорту

• Код у репозиторії, який належить вам, з README про запуск, збірку та змінні середовища
• Застосунок запускається локально з чистого клону
• База даних експортована і відновлення перевірене; завантажені файли скопійовано
• Обрано хост під тип застосунку, а також керовану базу даних і сховище
• Усі змінні середовища задано з живими значеннями на новому хості
• Вебхуки, перенаправлення OAuth і посилання в email оновлено
• DNS перемкнено, стару версію тимчасово залишено, потім видалено
• Резервні копії, моніторинг і список доступу налаштовано

Експорт з Mythex

У Mythex ви володієте кодом, який створюєте. На тарифі Pro можна завантажити проєкт як архів через Project settings → Export або підключити GitHub і виконувати push та pull з власним репозиторієм; на безкоштовних тарифах код можна переглядати лише для читання, без експорту та синхронізації. Секрети та node_modules не входять до експорту, тож відтворіть секрети на новому хості. Кроки описано в документації: експорт і запуск деінде та GitHub, експорт та імпорт. Ви також можете залишити хостинг на Mythex і використовувати синхронізацію з GitHub лише як власну копію та спосіб передачі; якщо ж переходите, вимкніть застосунок у Mythex, коли новий хост уже працює.

Запитання