Три часа ночи.
Прод лежит.
А где у нас, собственно, что?
Моя боль
На работе я пришёл вести один Rails-проект, а через полгода у меня было уже два бэкенда (новый бренд и старый), сайт-документация, пара мобильных приложений и прошивка для умного замка. Репозитории разбросаны по разным местам, DNS в трех разных местах, CI, CDN, Docker Registry, аппсторы, SSL, трекинг ошибок, тикеты, логи.
В среднем 10 мест на проект на 7 проектов на 2 окружения (staging + production). Когда прод падает, первые полчаса ты просто пытаешься понять, куда бежать и что вообще мониторить.
В хобби-проектах казалось бы должно быть полегче — их пять штук, некоторые открываю раз в месяц. Но тут те же головняки: репа, DNS, трекинг ошибок, аналитика, SEO-инструменты… и иногда я днями не могу исправить баг, потому что не помню, где лежат исходники — в Lovable, Replit или Cursor?
Итог: проектов и сервисов море, всё в голове не удержать, каждый раз тратить минуты на “куда же я это записал?” — бесит и крадёт время.
Понятные готовые решения
1. Закладки браузера. Да, но теряются когда переезжаешь на другой браузер + неудобно, когда реально много всего + и не поделиться с командой.
2. Confluence. Который всех бесит. И который тоже сначало надо найти. А потом в нем найти куда что в каком виде записать.

3. GitLab. Неплохо разогнался в свое время, натолкал в себя CI, Docker Registry, тикеты, канбан досок, инциденты, security audit и прочего, но увы, так и не стал сервисом единого окна. В общем, ссылки две-три четыре, он вам способен сократить, но на этом все.
4. Terraform. Увы, для девопсов, а не для обычных людей, все туда не затолкать, описывать там приходится даже то что тебя мало интересует (все эти policies и subnets), все это со временем разъезжается. В большинстве случаев получается из пушки по воробьям.
Увы, ни один из этих вариантов ни достаточно минималистичен, ни минимально достаточен :(
Мое решение
Yaml-файл в git-репозитории каждого проекта, в который по ходу дела докидывается инфа типа ip-адреса, где у нас зарегана почта, где управляем DNS-записями:
makefile.site:
registrar: gandi
dns: Route 53
hosting: https://carrd.com
mail: zoho
Я добавляю даже не ссылки, а просто названия сервисов, когда это все что я знаю. Уходит на это три секунды, но в следующий раз будет ясно куда бежать. И когда я в следующий раз доберусь до AWS, я не поленюсь, и докину прямую ссылку на настройку DNS вместо текстового "Route 53".
Следующий логичный шаг - рендерить мини-дэшборду со ссылками и заметками чтобы она всегда была под рукой. После нескольких попыток остановился на таком варианте:

Особенности формата
Данные лежат под корневым ключем. Несколько корневых ключей - несколько карточек.
Корневой ключ может быть именем домена как в моих примерах, а может быть просто production/staging - здесь полная гибкость.
Ниже я привел базовые структуры, и как они рендерятся:
-
Ключ+ссылка и ключ+значение:
корневой ключ → заголовок карточки; иконки автоподтягиваются из интернетов, ссылки нажимаются, текстовые значения уезжает в отдельный блок -
"Хэш" со ссылками:
ссылки рендерятся в виде pills, принадлежат своей секции -
"Хэш" со значениями:
по клику копируется в буфер обмена -
Список:
просто список, без постобработки
Формат максимально простой и гибкий. Сейчас нет никакого фиксированного, или даже требуемого набора ключей. Все отдается на откуп автора.
card:
hetzner: 12.43.21.123
А можно и эдак:
card:
hosting:
provider: hetzner.com
ip: 12.43.21.123
managed_by: easypanel
Скорее всего подъедет пара зарезервированных слов project и tags для удобной группировки и навигации по большому кол-ву карточек, но пока полная свобода.
Как попробовать
Установить:
curl -sL
get.sitedog.io
| sh
Закинуть в папку проекта
sitedog.yml
с вашими заметками (ну илиsitedog init
сгенерит пустой файл для вас).Дальше
sitedog live
пока реадктируете файл и хотите живые обновления карточек, иsitedog render
, когда закончили, у нужен финальный html-файл.
Исходники утилиты и установщика в открытом доступе здесь: github.com/sitedog-io/sitedog-cli. Open Source, MIT, все дела.
Как попробовать если лень
Если хочется потыкать формат, не устанавливая ничего — вот live editor.
Редактируйте YAML — и сразу смотрите, как рендерятся карточки.
Никакой регистрации, просто интерфейс.
Идеи по использованию
Хоть тулза и называется SiteDog, она позволяет хранить информацию не только о сайтах.
Тип проекта |
Описание |
Примеры данных |
Кому подойдет |
---|---|---|---|
Веб-сайты |
Отслеживание основной инфраструктуры сайтов |
DNS, хостинг, SSL, CDN, аналитика, домены |
Веб-разработчики, агентства |
Внутренние сервисы |
Учёт корпоративных инструментов и API |
Внутренние API, базы данных, мониторинг, логи |
DevOps, системные администраторы |
Серверная инфраструктура |
Управление серверами и их компонентами |
IP-адреса, кому выдан доступ, бэкапы, мониторинг ресурсов |
Системные администраторы |
Мобильные приложения |
Отслеживание релизного цикла мобилок |
App Store, Google Play, Firebase, push-уведомления, аналитика |
Мобильные разработчики |
SEO-аудит |
Централизованный контроль SEO-метрик |
Google Search Console, Яндекс.Вебмастер, семантика, позиции |
SEO-специалисты, маркетологи |
Домены и поддомены |
Управление доменным портфелем |
Регистраторы, DNS-записи, сроки продления, редиректы |
Владельцы больших доменных портфелей |
API и интеграции |
Каталог используемых API и сервисов |
Инфа об API-ключах, лимиты, документация |
Backend-разработчики |
Все это естественно можно комбинировать в любых комбинациях под собственные нужды.
Ключи/токены/сертификаты
Если у вас глаз зацепился за упоминание API-ключей, то я не имею в виду сами ключи. Речь идет о вспомогательной информации такого рода:
api_key: stripe-prod #(название/алиас)
api_key_expires: 2028-06-30
api_token: github-deploy-token-kirill
ssh_access_shared_to: ivan, kirill
ssl_cert_expires: 2025-12-01
Для самих ключей/токенов есть специализированные инструменты - там им и место.
Итого
В своем текущем виде - это симпатичная маленькая command line утилита:
почти не требует внимания;
даёт быстрый доступ к (часто критически важной) информации “где у нас что”;
встраивает в процесс разработки актуализацию инфраструктурной инфы;
можно добавить в Git hooks и CI/CD, чтобы рендерить и заливать HTML версию.
Сейчас допиливается простой бэкенд, чтобы можно было собирать "карточки" со всех проектов в одном месте — с поиском, фильтрацией, группировкой по тегам и окружениям.
Планы по развитию
Некоторые фичи напрашиваются сами собой:
Авто-энричмент - чтобы по неполным данным, например
hosting: hetzner
, оно бы само догадывалось достать ссылку и иконкуАвто-дискавери - подключаешь свой гитхаб/гитлаб, даешь доступ до репозиториев, и изменения оно добирает само.
-
Сделать так чтобы оно буквально всегда было под рукой:
Экстеншн для Chrome (чтобы встраивалось в UI Github/GitLab),
Экстеншн для VS Code (и других редакторов?)
+Наверняка вылезет еще куча вариантов куда это можно встроить
Все из этого я придумал еще на этапе проработки идеи, но когда дело дошло до кода - возникло несколько затруднений.
Технические подробности
На самом деле довольно неочевидно на каком языке разрабатывать такую штуку.

Я предпочитаю руби, но я хорошо понимаю что для большинства это экзотика, и заставлять устанавливать интерпретатор Ruby ради такой маленькой утилиты - это чересчур.
Из интересных вариантов: писать все на Node – тогда можно будет переиспользовать код и в CLI-утилите, и в live-editor, и в экстеншнах. Но, честно говоря, душа не лежит.
Опять же, в плане доставки cli-утилиты, завязываться на Node - не лучший вариант.
Вариант "летим в космос": писать все на Clojure, и из Clojure-кода же генерить имплементацию на других языках, и сами экстеншны ?. Звучит заманчиво, но такими экспериментаи я займусь когда выйду на пенсию.
Если не понятно какое решение принимать, то лучше его отложить (до появления новой информации. И делать минимально необходимое с учетом текущей реальности. Реальность:
Для live-editor в браузере по-любому нужно решение на JS.
CLI доставлять лучше всего бинарником.
Хорошо бы чтоб работало под все операционки.
Текущее решение: рендерилку оставить на JS, а CLI сделать на Go, для удобства дистрибуции. Облако - на Ruby, потому что one love!
Процесс > Инструмент
На самом деле хочется конечно не ещё одну "волшебную" тулзу, а ощущение, что где-то есть порядок, который мне подчиняется.
В этом смысле SiteDog — это не решение “всё и сразу”. Это решение 20/80, когда буквально "what you see is what you get".
По сути я вам здесь предлагаю даже не инструмент, а практику для внедрения в свой процесс разработки. Именно практика первична. Рендерилка, облако, авто-энричмент - это уже все вишенки на торте, которые просто глупо не запилить вокруг такой практики.
Философия решения:
Less in More: не втаскиваем тяжеловесные IaC-решения пока реально не нужно → когда втаскиваем, sitedog все еще полезен для вещей которые не хэндлятся такими решениями
Не напрягаемся: на поддержание актуальности тратим микроусилия по ходу дела → пользуемся накопительным эффектом
Лучше неидеально, но прямо сейчас: накидываем буквально все что вспоминается, пофиг в каком виде → всегда можно будет проапдэйтить позже
"We eat our own dogfood":
Вот как выглядит колода карточек самого Sitedog:

Спасибо что дочитали!
Если вы узнали в моем рассказе свою боль — попробуйте.
Если не узнали — расскажите, как у вас устроено.
Баги, идеи, фидбек — welcome в issues или прямо в комменты.
⭐️ GitHub: github.com/sitedog-io/sitedog-cli
☁️ Бета-доступ в облако — через форму в репозитории проекта.
Комментарии (6)
m1skam
19.06.2025 09:54Для меня странный подход.
ИМХО единым окном вполне может быть мониторинг. Обогатить метрики данными в виде кто делал последний коммит, url репозитория, кто главный мейнтейнер и тд и вот у вас вся информация на дашборде приложения. Прошли по ссылке на репозиторий, вот вам README.md который сразу отображается и в котором все расписан что, где, кто использует.
4. Terraform. Увы, для девопсов, а не для обычных людей, все туда не затолкать, описывать там приходится даже то что тебя мало интересует (все эти policies и subnets), все это со временем разъезжается. В большинстве случаев получается из пушки по воробьям.
Если при наличии тераформа, вы позволяете себе и коллегам вносить в инфраструктуру правки, через веб интерфейс, то вы сами себе злобный буратино, инструмент тут не виноват.
nem Автор
19.06.2025 09:54В мониторинг ты не положишь ссылку на настройку DNS, когда истекает GitLab токен, и где у нас CDN. В ридми можно, да. А вы что для мониторинга используете?
Про терраформ было скорее в обратную сторону у меня идея - что не надо втаскивать терраформ в хобби проект, пока можно обойтись yaml-файлом
m1skam
19.06.2025 09:54В мониторинг ты не положишь ссылку на настройку DNS, когда истекает GitLab токен, и где у нас CDN. В ридми можно, да. А вы что для мониторинга используете?
Технически возможно, но насколько это имеет смысл? Мы использовали в начале пути связку Prometheus + Grafana, сейчас чуть сложнее, а именно prometheus с remote-write в mimir и в него уже смотрит Grafana, рядом Loki, Tempo. Дополнительно в каждом кластере крутитися OpenTelemetry Collectors, Promtail, Events Exporter и тд. Смотрим в сторону Alloy, на тестовом кластере планируем заменить им Prometheus. Тестировали VictoriaMetrics, но отказались от нее.
Про терраформ было скорее в обратную сторону у меня идея - что не надо втаскивать терраформ в хобби проект, пока можно обойтись yaml-файлом
Прошу прощения, из это было не совсем понятно.
Uranic2
Вот это велосипед!
Освойте уже obsidain + пару плугинов
nem Автор
Спасибо за идею! Плагин для Obsidian надо тоже запилить!