Почему свой сервер, а не готовые платформы

Когда решил наконец завести блог, первый вопрос был не «о чём писать», а «где».

Варианты очевидны: Medium, Substack, Hashnode, Notion-страница, Ghost на чужом хостинге. Всё это работает. Всё это быстро настраивается. И всё это меня не устраивало.

Почему не готовые платформы

Не из принципа «всё сам» — это было бы глупо. Просто есть конкретные причины.

Контроль над данными. Пост на Medium — это пост на Medium. Их алгоритм, их paywall, их решение о том, кому показывать. Я пишу для людей, которые зашли на мой сайт, а не для читателей платформы.

Производительность. Готовые платформы тянут мегабайты JS ради «редактора», который мне не нужен в браузере читателя. Статический сайт с правильной конфигурацией отдаёт страницу быстрее, чем большинство SPA успевает инициализироваться.

Собственные пайплайны. Я занимаюсь DevOps — было бы странно не иметь нормального CI/CD для собственного блога. Git push → сборка → деплой → инвалидация кэша. Без магии, без vendor lock-in.

Просто интересно. SEO-оптимизация, HTTP-заголовки, кэширование на уровне Nginx, Web Vitals — это то, о чём я хочу писать, потому что есть выработнная экспертность. Сложно писать о производительности сайтов, если сам сидишь на платформе, где ты это не контролируешь.

Как это устроено

Блог живёт на ru.blog.lis.im — отдельном VPS. Статика собирается и раздаётся Nginx’ом. Деплой через собственный пайплайн: коммит в репозиторий запускает сборку, артефакт улетает на сервер.

Никакого Netlify или Vercel — не потому что они плохие, а потому что здесь это учебный полигон.

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