Где размещено ваше приложение: найти репо, хостинг, БД и домен

Что на самом деле значит «где живёт ваше приложение»

Когда кто‑то спрашивает, где размещено ваше приложение, обычно речь не об одном элементе. Они пытаются проследить путь от клика пользователя до систем, которые обеспечивают работу приложения.

У большинства приложений есть четыре отдельных «дома». Перепутать их легко — и это может стоить часов работы:

• Код (репо): где хранится и редактируется исходный код (GitHub, GitLab, Bitbucket или внутри инструмента вроде Replit).
• Хостинг (runtime): где живое приложение работает, когда пользователи его посещают (Vercel, Netlify, Render, Fly.io, AWS, VPS и т. п.).
• База данных: где хранятся данные (пользователи, заказы, контент) — Postgres, MySQL, MongoDB или управляемый продукт.
• Домен и DNS: настройки, которые связывают ваше доменное имя с хостингом и другими сервисами (почтовые записи, записи верификации и т. д.).

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

Можно безопасно поделиться многим — и это ускорит работу. Обычно можно назвать провайдеров, прислать скриншоты дашбордов (секреты закрыть), текст ошибок и имена сервисов. Приватным остаётся всё, что даёт доступ: пароли, приватные ключи, API‑токены, строки подключения к БД и полные значения переменных окружения.

Понимание этих мест превращает отладку из угадывания в проверку. В FixMyMess часто попадают AI‑созданные прототипы, где репозиторий есть, но деплой идёт с другой ветки, либо секреты оказались раскрыты. Как только репо, деплой и база чётко определены, исправления становятся проще и быстрее.

Короткая заметка, чтобы зафиксировать основы

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

Скопируйте и заполните это:

• Repo: провайдер + имя репозитория + кто может дать доступ
• Hosting: провайдер + имя проекта/приложения + способ деплоя (авто из git, вручную)
• Database: провайдер + имя базы + где хранятся учётные данные
• Domain/DNS: регистратор/DNS‑провайдер + домен + кто может редактировать записи
• Последняя рабочая версия: когда всё работало в последний раз и что изменилось

Если AI‑прототип вдруг сломался после «малой правки», эта заметка предотвращает классическую ошибку — править не ту среду.

Шаг за шагом: как найти репозиторий с кодом

Если вы ещё не знаете, где размещено приложение, начните с репо. Репозиторий — лучшее место, чтобы увидеть, что у вас есть, что изменилось последним и что кто‑то реально может исправить.

Вернитесь в AI‑билдер или инструмент, в котором вы работали. Многие инструменты (Lovable, Bolt, v0, Cursor, Replit) имеют настройки вроде GitHub, Repository, Export или Sync, которые показывают, куда был отправлен код. Если видите подключённый аккаунт — запишите организацию или имя пользователя.

Если не помните, куда ушёл код:

• Откройте инструмент, в котором собирали проект, и найдите любые подключения Git/Repository или историю экспорта.
• Поиск в почте по приглашениям в репо и уведомлениям типа «deployment succeeded», «build failed» или письмам от GitHub.
• Проверьте аккаунты GitHub, GitLab или Bitbucket, которыми вы пользовались, в разделах Organizations и Repositories.

Когда найдёте репо, зафиксируйте то, что спросят:

• Владелец репозитория (человек или организация)
• Название репо
• Кто имеет доступ (и кто может дать доступ)
• Ветка по умолчанию и дата последнего коммита

Проверка здравого смысла: если последний коммит — несколько месяцев назад, а приложение недавно изменилось, возможно, вы смотрите не на то репо или инструмент так и не запушил последние изменения.

Шаг за шагом: как определить хостинг и деплои

Когда спрашивают «где размещено ваше приложение», обычно имеют в виду два момента: где живёт публичный сайт и как туда попадает новый код.

Начните с места, в котором вы создавали приложение. У многих AI‑билдеров и шаблонов есть страница Deploy, где видно подключённый аккаунт провайдера (например, Vercel или Netlify). Если написано «connected to GitHub», деплои часто идут автоматически из репозитория.

Если вы не уверены, какой у вас хост, проверьте почту и выписки по оплате на предмет имён вроде Vercel, Netlify, Render, Fly.io, Railway или облачных провайдеров (AWS, GCP, Azure). Если таких несколько — отметьте, какой из них отдаёт публичный сайт, а какой — фоновые задачи или базу.

В панели хостинга для нужного проекта запишите:

• Имя проекта/приложения, как показано в хосте
• Окружения (production, preview, staging) и какой URL — это продакшн
• Время последнего успешного деплоя (и с каким коммитом/версией)
• Где хранятся логи билда и runtime

Затем подтвердите, как происходят деплои. Посмотрите настройки вроде «deploy on push» или «connected to main branch». Если деплой ручной — запишите, кто может его сделать и что именно нажимает.

Практический пример: главная страница обновляется при merge в main, а API остаётся сломанным. Часто это значит, что фронтенд на Vercel, а бэкенд развернут в другом месте (Render, Fly.io или отдельный облачный проект). Запись обоих мест экономит время.

Если вы приносите эти данные в FixMyMess для бесплатного аудита, мы сразу переходим к нужным логам и пайплайну деплоя, вместо того чтобы тратить время на поиск, где всё вообще работает.

Шаг за шагом: как найти базу данных вашего приложения

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

1) Начните с распространённых управляемых баз

Для AI‑инструментов и шаблонов база часто — управляемый сервис. Ищите Supabase, Neon, PlanetScale, Firebase, MongoDB Atlas или AWS RDS в списке инструментов, счётах или письмах. В панели хостинга проверьте раздел «connected resources».

2) Проверьте настройки хостинга на наличие переменных для БД

В настройках приложения на хостинге найдите Environment Variables или Secrets. Не копируйте секреты — цель здесь выявить провайдера и целевую базу.

Распространённые имена переменных:

• DATABASE_URL или DB_URL
• POSTGRES_URL или PGHOST
• MONGO_URL или MONGODB_URI
• SUPABASE_URL (часто идет вместе с ключами)
• FIREBASE_PROJECT_ID

По имени переменной и несекретной части (например, hostname) вы обычно легко определите провайдера.

3) Просканируйте репо на предмет подсказок о БД

В репозитории ищите слова «supabase», «prisma», «mongoose», «firebase», «postgres», «mysql» или «mongodb». Проверьте файлы конфигурации вроде .env.example, prisma/schema.prisma, firebase.json или docker-compose.yml. Они часто показывают тип БД, даже если реальные секреты хранятся отдельно.

4) Зафиксируйте минимальные детали (без секретов)

Запишите:

• Провайдер
• Имя проекта или ID проекта
• Регион (если указан)
• Имя базы данных
• Есть ли разделение на dev и prod

Пример: если в хостинге есть DATABASE_URL, а hostname содержит «neon.tech», можно сказать поддержке «Neon Postgres, проект X, регион Y, отдельные prod и dev». Этого обычно достаточно, чтобы начинать диагностику без передачи учётных данных.

Шаг за шагом: как сопоставить аутентификацию и ключевые интеграции

Аутентификация — частый узкий профиль. «Где размещено приложение?» недостаточно, если никто не может сказать, какой продукт аутентификации используется, какие домены разрешены и где заданы секреты.

Начните с определения провайдера аутентификации и места его конфигурации. Ищите в репо файлы, связанные с auth (auth, middleware, providers), и в настройках хостинга — переменные окружения. Популярные провайдеры: Clerk, Auth0, Supabase Auth, Firebase Auth или кастомные маршруты логина.

Запишите:

• Какой провайдер используется (и имя проекта/приложения внутри него)
• Какие методы входа включены (email, Google, GitHub и т. п.)
• Какие production redirect URL и разрешённые домены
• Где хранятся сессии (cookies, JWT или база данных)
• Точный текст ошибки (или скриншот с скрытыми секретами)

Большинство «работает локально, падает в проде» проблем — небольшие несовпадения: redirect URL всё ещё указывают на localhost, разрешённые домены не включают реальный домен или настройки cookie не соответствуют HTTPS.

Карта симптомов:

• Цикл редиректов после входа: неверный redirect URL или домен cookie
• «Invalid redirect_uri»: не обновлены разрешённые redirect URL для продакшна
• «Unauthorized» только в проде: пропущенная env‑переменная/секрет в настройках хостинга
• Вход работает, но пользователь сразу выходит: cookie-сессия блокируется или неверен JWT‑секрет

Пример: Google‑вход работает на ноутбуке, но на живом сайте вы видите «Invalid redirect_uri». Часто решение — добавить продакшн callback URL в дашборд провайдера и обновить переменные окружения в хостинге.

Шаг за шагом: как найти настройки домена и DNS

Домен — это главный вход. Если DNS указывает не туда (или у вас нет доступа), правки, которые могли бы занять минуты, могут тормозиться днями.

Начните с имени домена (пример: yourapp.com). Ищите в почте слова «domain renewal», «registrar» или само доменное имя. Компания, которая шлёт квитанции за продление, часто и есть регистратор (GoDaddy, Namecheap, Cloudflare и т. п.).

Затем подтвердите, где реально управляется DNS. Это может отличаться от регистратора. В панели регистратора ищите DNS, Nameservers или DNS Management. Если nameservers указывают на другую компанию (часто Cloudflare), значит правки нужно делать там.

В зоне DNS обычно полезны следующие записи:

• A: указывает корневой домен на IP
• CNAME: часто указывает www на другой hostname
• TXT: используется для верификации домена, почтовых настроек и некоторых auth‑провайдеров

Затем проверьте, куда указывает домен и активен ли SSL. Предупреждения браузера, недавние изменения DNS или конфликтующие записи — частые признаки несоответствия домену и текущему хостингу.

Пример: прототип работает по preview‑ссылке, но не по реальному домену. Исправление часто сводится к обновлению одного CNAME или добавлению TXT, но это возможно только при доступе к правильному DNS‑провайдеру.

Перед обращением за помощью зафиксируйте:

• Домен(ы) и используете ли вы www
• Регистратор и DNS‑провайдер (если разные)
• Кто имеет доступ для редактирования DNS
• Текущие ключевые записи (A, CNAME, TXT) и недавние изменения

Быстрый чеклист перед обращением за помощью

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

Держите это как простую заметку, которую можно вставить в запрос в поддержку. Если вы чего‑то не знаете — напишите «unknown», а не домысливайте.

• Repo (код): владелец и имя репо, main ветка, дата/время последнего коммита, которую вы видите.
• Хостинг: провайдер, имя проекта/приложения, production URL, время последнего успешного деплоя.
• База данных: провайдер, имя/ID проекта, разделены ли prod и dev.
• Домен и DNS: регистратор, где управляется DNS и куда сейчас указывает домен (IP в A или цель CNAME).
• Доступ и владение: кто сейчас может выдать права и какие email‑адреса владеют аккаунтами.

Пример: вход сломан, но репо у подрядчика в GitHub, сайт деплоится из другого аккаунта, а DNS всё ещё указывает на старую preview‑ссылку. С чеклистом разработчик быстро запросит нужные права и найдёт настоящий продакшн за минуты, а не за дни.

Распространённые ошибки, которые тормозят поддержку

Когда вы не знаете, где размещено приложение, помощники тратят первый час на поиск базовых вещей вместо исправления проблемы.

Типичные блоки:

• Подразумевается «оно в GitHub», когда на деле есть только скачанный zip или копия в билдере. Без настоящего репо (история, ветки, чёткая основная версия) трудно просмотреть изменения или безопасно откатить.
• Путаница между preview URL и настоящим продакшн‑сайтом. Preview‑ссылка может работать, а оплаченный продакшн‑домен указывать в другое место.
• Отсутствие доступа к нужным аккаунтам. У вас может быть доступ к AI‑билдеру, но нет доступа к хостингу, регистратору домена или дашборду базы.

Пару советов, чего не делать при сборе данных:

• Не публикуйте скриншоты с API‑ключами, паролями или приватными токенами. Если что‑то было раскрыто — смените его.
• Не делайте «быстрых» правок в DNS без записи того, что вы изменили. Пропагация занимает время, и легко потерять контроль над тем, что именно ломает.
• Не переименовывайте проекты, не удаляйте окружения и не отключайте интеграции «чтобы привести в порядок» до того, как кто‑то посмотрит. Это может удалить следы, нужные для диагностики.

Реалистичный пример: как превратить шаткий AI‑прототип в починимый проект

Основатель имеет демо, которое выглядит отлично на скриншоте. Его сгенерировали AI‑инструментом, и лендинг загружается нормально. Но когда реальные пользователи пытаются войти, живой сайт выдаёт ошибки и перекидывает их на главную.

Они выбираются, ответив на один вопрос полностью: где живёт приложение. Не только сайт, но репо, деплой, база и домен.

Ищут в почте, находят забытый репозиторий на GitHub, затем проверяют хостинг и обнаруживают проект на Vercel. Деплои падают, потому что переменные окружения не были установлены в панели хостинга.

Когда деплои становятся зелёными, вход всё ещё ломается. Они находят базу — Supabase — и понимают, что её схема старая, оставшаяся от раннего прототипа. Небольшая правка схемы (или миграция) восстанавливает поток аутентификации.

Наконец домен всё ещё указывает на старую цель. Они обновляют DNS на правильный хост и подтверждают SSL, чтобы браузеры перестали показывать предупреждения.

Что ускорило починку — не везение, а готовые детали:

• Где репо и кто даёт доступ
• Какой провайдер хостинга и статус последних деплоев
• Имена переменных окружения (не их значения)
• Провайдер базы и имя проекта
• Регистратор домена и где управляется DNS

Следующие шаги: упакуйте информацию и получите помощь быстрее

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

Держите «инвентарь приложения» коротким, но полным:

• Repo: где хранится код + имя основной ветки
• Hosting: провайдер + имя проекта/приложения + как происходят деплои (ручные или автоматические)
• Database: провайдер + имя БД + где приложение читает параметры подключения (env vars)
• Domain/DNS: регистратор + где управляется DNS + куда указывает
• Auth/интеграции: провайдер логина + ключевые сторонние сервисы (платежи, почта, хранилище)

Доступ обычно — узкое место, но делиться паролями рискованно. Предпочитайте приглашения по email с минимально необходимыми правами и удаляйте доступ после завершения работ.

Если приложение создано инструментами вроде Lovable, Bolt, v0, Cursor или Replit, сфокусированный аудит часто — самый быстрый первый шаг. AI‑сгенерированные прототипы часто скрывают проблемы вроде открытых секретов, сломанных потоков аутентификации или хрупкой логики базы. FixMyMess (fixmymess.ai) заточен под такие случаи: диагностировать кодовую базу и починить нужное, чтобы приложение надёжно работало в продакшне.