🌲 Git Worktree: как работать в двух ветках одновременно?

Представь ситуацию: ты пишешь огромную фичу в ветке feature, у тебя открыты десятки файлов, проект запущен. Вдруг прилетает критический баг в main, который нужно поправить прямо сейчас. Обычно ты делаешь stash, переключаешься на main, правишь, возвращаешься и делаешь stash pop. Это долго и сбивает фокус.

Задача:
— Работать над main и feature одновременно.
— Иметь две разные папки на компьютере для одного и того же репозитория.

Решение:

Команда git worktree позволяет «развернуть» любую ветку в отдельную соседнюю папку. Ты просто открываешь её во втором окне IDE.

# 1. Создаем отдельную папку для ветки hotfix (Git сам создаст папку и переключит ветку)
git worktree add ../my-project-hotfix main

# 2. Теперь у тебя на компьютере два независимых рабочих пространства:
# - ~/projects/my-project (твоя текущая фича)
# - ~/projects/my-project-hotfix (чистый main для правок багов)

# 3. Когда баг исправлен и запушен, удаляем рабочее дерево
git worktree remove ../my-project-hotfix

Почему это киллер-фича?
— Никаких переключений — тебе не нужно останавливать сервер, пересобирать зависимости (npm install) или прятать код в stash.
— Параллельные тесты — ты можешь запустить тесты в одной папке и продолжать писать код в другой.
— Чистота — файлы не перемешиваются, ты не рискуешь случайно закоммитить код фичи в ветку багфикса.

Совет: Чтобы посмотреть список всех активных рабочих деревьев, используй команду git worktree list. Это поможет не забыть удалить старые папки, когда они станут не нужны.

🔥 — если worktree звучит как спасение для больших проектов
🤝 — если по старинке клонируешь репозиторий второй раз в новую папку

➡️ GitHub Ready | #урок

🚀 Turborepo: Как собирать гигантские проекты за пару секунд?

Когда у тебя в монорепозитории лежат три приложения и пять общих библиотек, обычный запуск тестов или сборка (build) превращаются в пытку. Ты меняешь одну строчку в UI-китовой кнопке, а твой компьютер начинает пересобирать вообще всё.

Задача:
— Перестать тратить по 10 минут на ожидание билда в CI/CD и локально.
— Запускать только те задачи, которые реально затронуты изменениями.

Решение:

Внедряем Turborepo — инструмент, который превращает выполнение скриптов в умный и кэшируемый процесс.



1. Умное кэширование (Caching)
Turborepo запоминает хэш файлов и результат их сборки.
— Если ты нажал build, он собрал проект.
— Ты ничего не менял и нажал build снова? Turborepo отдаст результат из кэша мгновенно.
— Кэш можно шерить с коллегами через облако: если кто-то один собрал ветку, остальным скачается готовый билд.

2. Граф зависимостей (Task Graph)
Ты объясняешь Turbo, как связаны твои задачи. Например: «Не собирай веб-сайт, пока не готова библиотека стилей». Он сам построит оптимальный маршрут и запустит всё параллельно, где это возможно.

3. Нулевая настройка
Тебе не нужно переписывать весь проект. Достаточно добавить один файл turbo.json, где ты описываешь, какие папки (например, dist) нужно кэшировать и от чего зависят твои команды.

Почему это маст-хэв?
— Экономия времени: билд в CI/CD сокращается с минут до секунд.
— Фокус на коде: тебе не нужно помнить, какие пакеты нужно пересобрать после изменений — Turbo сделает это за тебя.
— Кросс-платформенность: работает одинаково быстро и на Mac, и на Linux, и в облачных пайплайнах.

Совет: Чтобы начать, просто введи npx turbo build. Он подхватит настройки твоих воркспейсов (NPM, Yarn или PNPM) и сразу начнет кэшировать задачи.

🔥 — если уже ощутил мощь кэша в CI/CD
🤝 — если по старинке ждешь сборку и пьешь чай

➡️ GitHub Ready | #урок

⚔️ Nx vs Turborepo: Что выбрать для проекта в 2026?

Если ты решил переезжать на монорепозиторий, перед тобой два главных игрока. В 2026 году разрыв между ними стал еще понятнее: это битва между «простотой и скоростью» и «инфраструктурой на стероидах».

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

Решение:

Выбор зависит от того, насколько «умным» должен быть твой репозиторий.



1. Turborepo (Скорость и простота)
Это «гоночный болид» от Vercel. Его главная цель — сделать билд максимально быстрым.
— Плюсы: Настройка за 10 минут. Он не лезет в структуру твоего кода, а просто кэширует задачи. Идеально для JS/TS проектов на 5–50 пакетов.
— Минусы: Меньше инструментов для контроля архитектуры. В 2026 году он всё еще остается в основном в рамках экосистемы Node.js.

2. Nx (Мощность и контроль)
Это «швейцарский нож» и целая платформа. Nx не просто запускает задачи, он понимает связи между каждой строчкой кода.
— Плюсы: В 2026 году Nx внедрил AI-агентов для самолечения билдов и детекции багов. Он поддерживает не только JS, но и Python, .NET, Go. Есть генераторы кода и строгие правила: например, можно запретить библиотеке UI зависеть от API-клиента.
— Минусы: Высокий порог входа. Конфигов будет больше, и тебе придется выучить «путь Nx».

Что выбрать?
— Выбирай Turborepo, если у тебя небольшая или средняя команда, вы пишете только на TS и вам просто нужно, чтобы npm run build не шел вечность.
— Выбирай Nx, если у тебя огромный энтерпрайз, разные языки программирования (Polyglot) и ты хочешь, чтобы инструмент сам генерировал код и следил за архитектурными границами.

Совет: В 2026 году оба инструмента поддерживают удаленное кэширование. Это значит, что если твой CI собрал проект, тебе не нужно собирать его локально — ты просто скачаешь готовый результат.

🔥 — если за минимализм Turborepo
🛠 — если любишь мощь и порядок Nx

➡️ GitHub Ready | #урок

🕸 Граф зависимостей: как увидеть хаос в своём проекте?

Когда в монорепозитории становится больше 10 пакетов, понимать, что от чего зависит, становится невозможно. Кто-то импортировал тяжелую библиотеку в легкий UI-кит, и теперь сборка фронтенда тянет за собой половину бэкенда. Чтобы не гадать, нужно визуализировать Dependency Graph.

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

Решение:

Современные инструменты (Nx, Turborepo, Madge) умеют строить интерактивные карты твоего кода.



Как это сделать?

— В Nx: просто введи npx nx graph. Откроется браузер с крутой интерактивной схемой, где можно кликнуть на любой проект и увидеть, кто его использует.
— В Turborepo: используй npx turbo build --graph. Он создаст файл (например, в формате PDF или DOT), который покажет путь выполнения задач.
— Для обычного JS/TS: библиотека Madge. Команда npx madge --image graph.png src/index.ts нарисует связи между твоими файлами.

Почему это важно?

— Оптимизация сборки: если ты видишь, что маленькая утилита зависит от огромного фреймворка, её стоит отрефакторить, чтобы ускорить пайплайны.
— Архитектурный контроль: граф сразу подсветит «божественные объекты», от которых зависит всё вокруг. Это первые кандидаты на распил.
— Онбординг: новому разработчику проще один раз взглянуть на схему, чем неделю копаться в импортах.

Совет: В 2026 году графы стали «умными». Теперь они показывают не только связи кода, но и время сборки каждого узла. Если какой-то квадрат на схеме горит красным — значит, именно он тормозит всю твою команду.

🔥 — если любишь рассматривать графы своего проекта
🤝 — если и так держишь всю структуру в голове

➡️ GitHub Ready | #урок

🛡 Module Boundaries: Как запретить «плохие» импорты?

В больших проектах часто случается архитектурный кошмар: кто-то случайно импортировал логику из backend в frontend или заставил общую UI-библиотеку зависеть от специфичного бизнес-кейса. Это превращает код в запутанный узел. Module Boundaries — это автоматические правила, которые бьют по рукам за такие связи.

Задача:
— Установить четкие границы между слоями (Shared, Features, Apps).
— Гарантировать, что стабильные библиотеки не зависят от изменчивых фич.
— Пресечь появление циклических зависимостей на корню.

Решение:

Мы используем теги и правила линтера (ESLint), чтобы софт сам проверял архитектуру при каждой попытке импорта.



Как это работает (на примере Nx):

1. Раздаем теги: В конфиге каждого модуля прописываем его роль. Например, type:ui для компонентов и type:app для приложений.
2. Описываем правила: В .eslintrc.json добавляем логику:
— type:ui может зависеть только от других type:ui.
— type:app может зависеть от чего угодно.
— Запрещено: type:ui -> type:app.

Почему это спасает проект?

— Чистая архитектура: ты физически не сможешь создать импорт, который нарушает правила. IDE подсветит ошибку красным еще до того, как ты сохранишь файл.
— Ускорение тестов: если модули изолированы, при изменении одного компонента нужно тестировать только его, а не всё дерево зависимостей.
— Масштабируемость: новые разработчики не смогут случайно испортить структуру проекта, потому что правила «зашиты» в код.

Совет: Если ты не используешь Nx, похожую логику можно настроить с помощью плагина eslint-plugin-import и правила no-restricted-imports, либо через инструмент Sheriff. Это превращает архитектурные гайдлайны из пожеланий в закон.

🔥 — если за жесткий порядок в импортах
🤝 — если полагаешься на сознательность коллег на ревью

➡️ GitHub Ready | #урок

🔄 Type-Safe Sync: как подружить фронтенд и бэкенд без боли?

Самая частая причина багов в больших проектах — когда бэкенд изменил структуру ответа (API), а фронтенд об этом не узнал. Ты ждешь user.id, а прилетает user.uuid. Чтобы не переписывать типы вручную каждый раз, нужно использовать автогенерацию кода.

Задача:
— Гарантировать, что фронтенд всегда знает актуальные форматы данных бэкенда.
— Перестать писать API-клиенты (fetch/axios запросы) руками.
— Ловить ошибки несовместимости типов еще на этапе компиляции, а не в продакшене.

Решение:

Используем схему как «единый источник правды». Бэкенд описывает API, а фронтенд автоматически скачивает готовые типы и функции.



Как это реализовать в 2026 году?

— Swagger / OpenAPI: если бэк на Java, Python или Go, он генерирует openapi.json. Фронтенд запускает openapi-typescript и получает готовые интерфейсы.
— tRPC: если и фронт, и бэк на TypeScript, это ультимативное решение. Ты просто импортируешь типы роутов бэкенда во фронтенд. Если на бэкенде изменится поле в базе — фронтенд сразу «покраснеет» от ошибок в IDE.
— Zod + TanStack Query: бэкенд отдает схему валидации, а фронтенд использует её, чтобы гарантировать: данные, пришедшие извне, именно те, что мы ждем.

Почему это маст-хэв?

— Минус 90% багов на стыке систем: типизация пронизывает всё приложение насквозь.
— Скорость разработки: разработчику фронтенда не нужно лезть в документацию или Postman. IDE сама подскажет все доступные поля и методы через автодополнение.
— Автоматический рефакторинг: поменял название поля на бэкенде — и твоя IDE сразу покажет все места на фронте, где это поле нужно переименовать.

Совет: В 2026 году стандарт де-факто для TS-проектов — это tRPC или Kysely для связи с БД. Если у вас до сих пор «договорняки» в Телеграме о том, какое поле придет в JSON — самое время внедрить генерацию из схем.

🔥 — если за полную типизацию от БД до кнопки
🤝 — если доверяешь any и своей интуиции

➡️ GitHub Ready | #урок

📦 Оптимизация Docker: как сжать образ в 10 раз?

Если твой Docker-образ весит 1 ГБ, он медленно качается, долго деплоится и ест лишнее место на сервере. В 2026 году стандарт индустрии — это Multi-stage builds и использование легковесных базовых образов.

Задача:
— Уменьшить размер финального образа.
— Оставить в продакшене только скомпилированный код без лишнего мусора (исходников, кэша npm).

Решение:

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

# Этап 1: Сборка (Build)
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
RUN npm run build

# Этап 2: Финальный образ (Production)
FROM node:20-alpine
WORKDIR /app
# Копируем только билд и зависимости для продакшена
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/package*.json ./
RUN npm install --omit=dev

CMD ["node", "dist/main.js"]

Почему это работает?

— Alpine Linux: вместо тяжелого Debian (200 МБ+) мы берем Alpine (всего 5 МБ).
— Отсечение лишнего: в финальный образ не попадают src, tsconfig.json и тяжелые devDependencies (типы, линтеры, тесты).
— Слои: Docker кэширует каждый шаг. Если ты не менял package.json, этап установки зависимостей пролетит мгновенно.

Результат:
Образ на базе стандартного Node.js может весить 800+ МБ, а оптимизированный через Multi-stage и Alpine — всего 80–120 МБ.

Совет: Используй файл .dockerignore, чтобы Docker даже не пытался копировать в контекст сборки папку node_modules или логи с твоего компьютера. Это еще сильнее ускорит процесс.

🔥 — если выжимаешь максимум из каждого байта
🤝 — если не паришься и просто берешь node:latest

➡️ GitHub Ready | #урок

🛡 Distroless: Как сделать образ, который невозможно взломать?

Если тебе кажется, что Alpine (5 МБ) — это предел, то познакомься с Distroless от Google. Это образы, в которых нет вообще ничего: ни оболочки (sh/bash), ни пакетного менеджера, ни даже команды ls или cd. Только твое приложение и его зависимости.

Задача:
— Уменьшить размер образа до абсолютного минимума.
— Максимально защитить сервер: если хакер попадет внутрь контейнера, он не сможет выполнить ни одной команды, так как терминала просто не существует.

Решение:

Используем Multi-stage билд, но в качестве финального образа берем gcr.io/distroless.

# Этап 1: Сборка проекта
FROM node:20 AS builder
WORKDIR /app
COPY . .
RUN npm install && npm run build

# Этап 2: Финальный защищенный образ
FROM gcr.io/distroless/nodejs20-debian12
COPY --from=builder /app /app
WORKDIR /app

CMD ["dist/main.js"]

Почему это киллер-фича?

— Безопасность: В обычном образе хакер может скачать вредоносный скрипт через curl или wget. В Distroless этих утилит нет. Там нет даже rm, чтобы замести следы.
— Вес: Образ становится еще легче, так как вырезаны все системные библиотеки, не нужные для работы Node.js, Python или Java.
— Скорость: Чем меньше слоев и файлов, тем быстрее образ проверяется сканерами безопасности и разворачивается в кластере.

Результат:
Твое приложение работает в стерильной среде. Это золотой стандарт для крупных финтех-компаний и проектов с высокими требованиями к безопасности.

Совет: Если тебе всё же нужно «зайти» внутрь такого контейнера для отладки, используй временные контейнеры (Ephemeral Containers) в Kubernetes или специальные инструменты отладки, так как обычный docker exec -it ... sh выдаст ошибку.

🔥 — если безопасность на первом месте
🤝 — если важнее иметь возможность зайти в контейнер и «посмотреть, что там»

➡️ GitHub Ready | #урок

К такому не подготовишься 😱

🔔 Uptime Kuma: Как узнать о падении сервиса раньше пользователей?

Нет ничего хуже, чем узнать о том, что твой проект "лежит", из гневных сообщений в личке. Чтобы не проверять сайт каждые пять минут вручную, разработчики ставят Uptime Kuma — это стильный и бесплатный self-hosted мониторинг, который сделает всё за тебя.

Задача:
— Круглосуточно следить за доступностью сайтов, контейнеров и баз данных.
— Получать мгновенные уведомления в Telegram, Discord или Slack, если что-то сломалось.
— Видеть красивую статистику аптайма и времени отклика (пинг).

Решение:

Разворачиваем одну из самых популярных опенсорс-панелей мониторинга за пару минут через Docker.

# Запуск Uptime Kuma в Docker
docker run -d --restart=always -p 3001:3001 -v uptime-kuma:/app/data --name uptime-kuma louislam/uptime-kuma:1

Что она умеет?

— Разные типы проверок: HTTP(s), TCP, Ping, DNS, и даже проверка срока действия SSL-сертификата (она напомнит, когда пора его продлевать).
— Уведомления: Поддерживает более 90 сервисов. Самый простой вариант — создать бота в Telegram и вставить его токен.
— Status Page: Можно создать публичную страницу (как у больших сервисов), чтобы пользователи сами видели: сейчас идут технические работы или всё "зеленое".
— Proxy-поддержка: Легко работает за Nginx или Traefik.

Почему это лучше внешних сервисов?

— Бесплатно: Никаких лимитов на количество проверяемых сайтов или частоту запросов.
— Приватность: Все данные о твоих серверах хранятся только у тебя.
— Скорость: Ты можешь проверять локальные сервисы внутри своей сети, которые не видны из интернета.

Совет: Установи интервал проверки в 60 секунд. Этого достаточно, чтобы оперативно среагировать на проблему и при этом не создавать лишнюю нагрузку на сервер постоянными запросами.

🔥 — если следишь за каждым процентом аптайма
🤝 — если узнаешь о падении только от клиентов

➡️ GitHub Ready | #урок

📜 Dozzle: Как читать логи всех контейнеров в одном окне?

Когда у тебя запущено много сервисов, прыгать между ними через docker logs становится мучительно. Если Lazydocker хорош для терминала, то Dozzle — это идеальный веб-интерфейс для тех, кто хочет просто и быстро просматривать логи через браузер.

Задача:
— Видеть логи всех контейнеров в реальном времени в одном месте.
— Иметь возможность быстрого поиска по тексту во всех логах сразу.
— Не нагружать сервер тяжелыми системами вроде ELK (Elasticsearch, Logstash, Kibana).

Решение:

Dozzle — это крошечный сервис, который подключается к Docker-сокету и выводит всё в удобный UI.

# Запуск Dozzle за одну секунду
docker run -d --name dozzle -p 8888:8080 -v /var/run/docker.sock:/var/run/docker.sock amir20/dozzle:latest

Почему это удобно?

— Интеллектуальный поиск: ты можешь мгновенно отфильтровать логи по ключевому слову (например, Error или Timeout) сразу по всем запущенным контейнерам.
— Никакой базы данных: Dozzle не хранит логи на диске, он просто транслирует их. Это значит, что он практически не потребляет ресурсы сервера.
— Живой поток: логи подгружаются мгновенно без перезагрузки страницы.
— Простота: не нужно ничего настраивать в самих контейнерах — Dozzle сам подхватит всё, что запущено на хосте.

Кому это нужно?

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

Совет: Если ты выставляешь Dozzle в интернет, обязательно закрой его паролем через Reverse Proxy (например, Nginx или Traefik), так как в логах могут проскакивать конфиденциальные данные.


🔥 — если любишь чистоту и порядок в логах
🤝 — если по-прежнему грепаешь текстовые файлы в /var/lib/docker/containers

➡️ GitHub Ready | #урок

200 тыс.₽ сейчас РЕАЛЬНО базовый минимум ⏺️

Который нужен для комфортной жизни в любом месте⤵️

Не знаешь, где словить такой куш?

Удаленка в долларах 💸 — канал для профи из СНГ с вакансиями в стабильной валюте.

IT, маркетинг, дизайн, крипта: ты точно в этом разбираешься

Осталось только начать нормально зарабатывать!

15+ актуальных вакансий за сегодня уже в канале:
https://t.me/+qoCsrhInumQyN2Ni 🔗

🤖 Watchtower: Как забыть об обновлении Docker-контейнеров?

Обновление контейнеров вручную — это рутина: нужно зайти на сервер, сделать docker pull, остановить старый контейнер и запустить новый. В 2026 году это делает Watchtower. Он следит за выходом новых версий твоих образов в Docker Hub или другом реестре и сам перезапускает сервисы.

Задача:
— Всегда иметь актуальные версии софта и патчи безопасности.
— Автоматизировать процесс обновления без участия человека.
— Избежать простоев из-за ручного переповтора команд.

Решение:

Запускаем один контейнер Watchtower, который будет мониторить все остальные.

# Запуск Watchtower для автоматического обновления всех контейнеров
docker run -d \
  --name watchtower \
  -v /var/run/docker.sock:/var/run/docker.sock \
  containrrr/watchtower

Почему это удобно?

— Полная автономия: он сам проверяет наличие обновлений, скачивает их и перезапускает контейнер с теми же параметрами (те же порты, вольюмы и сети).
— Очистка мусора: с флагом --cleanup он удаляет старые образы после обновления, чтобы они не занимали место на диске.
— Выборочность: если ты не хочешь обновлять какой-то конкретный сервис (например, базу данных, где важна стабильность), просто добавь ему лейбл com.centurylinklabs.watchtower.enable=false.
— Уведомления: Watchtower может присылать отчеты об обновлениях прямо в Telegram.

Кому это нужно?

— Владельцам домашних серверов и небольших медиа-станций.
— Разработчикам для стейджинг-окружений, чтобы там всегда был свежий код из мастера.
— Тем, кто ценит безопасность и не хочет пропускать критические патчи библиотек.

Совет: Будь осторожен с обновлением баз данных (PostgreSQL, MySQL) в автоматическом режиме. Мажорные версии (например, с 15 на 16) могут требовать миграции данных, поэтому для них автообновление лучше отключать.

🔥 — если за полную автоматизацию
🤝 — если предпочитаешь обновлять всё под своим контролем

➡️ GitHub Ready | #урок

NtWARden

NtWARden — набор инструментов для анализа и исследования Windows

Инструмент инспекции системы Windows на базе ImGui + DirectX 11, поддерживает работу как в пользовательском режиме, так и в режиме ядра.

Позволяет перечислять внутренние структуры системы: процессы, сервисы, сетевые соединения, обратные вызовы ядра, SSDT, пулы ядра и т.д., а также включает встроенные функции анализа безопасности процессов (обнаружение шеллкода, выявление подмены модулей, детектирование перехватов системных вызовов и др.).

Cсылка на GitHub

➡️ GitHub Ready | #урок

🌐 Nginx Proxy Manager: как управлять доменами и SSL без боли?

Если у тебя на сервере крутится пять разных контейнеров (сайт, облако, мониторинг), тебе нужно как-то обращаться к ним по красивым адресам вроде api.myapp.com вместо 123.123.123.123:8080. Nginx Proxy Manager (NPM) — это удобная админка, которая позволяет разрулить трафик и выпустить SSL-сертификаты за пару кликов.

Задача:
— Привязать домен к конкретному порту контейнера.
— Включить бесплатный HTTPS (Let's Encrypt), чтобы браузер не ругался на соединение.
— Сделать всё это через понятный веб-интерфейс, не копаясь в конфигах Nginx.

Решение:

Разворачиваем NPM как основной входной узел (Reverse Proxy) для всех остальных сервисов.

# Пример docker-compose.yml для NPM
services:
  app:
    image: 'jc21/nginx-proxy-manager:latest'
    restart: unless-stopped
    ports:
      - '80:80'   # HTTP
      - '81:81'   # Админка
      - '443:443' # HTTPS
    volumes:
      - ./data:/data
      - ./letsencrypt:/etc/letsencrypt

Почему это маст-хэв?

— Простота: Добавление нового поддомена занимает 30 секунд. Ты просто вводишь имя хоста и IP-адрес контейнера.
— Автоматический SSL: Нажал галочку «Force SSL», и NPM сам свяжется с Let's Encrypt, получит сертификат и будет его обновлять.
— Безопасность: Можно закрыть любой сервис паролем (Access Lists) прямо через админку, даже если само приложение этого не умеет.
— Логирование: Ты видишь, кто и когда заходил на твои сайты, прямо в интерфейсе.

Кому это нужно?

— Тем, кто держит несколько проектов на одном VPS.
— Разработчикам, которым нужно быстро выкатить фронтенд и бэкенд на разные поддомены.
— Владельцам домашних серверов для доступа к своим инструментам извне.

Совет: Чтобы NPM мог обращаться к другим контейнерам по их именам (например, http://backend:5000), объедини их в одну Docker-сеть. Это избавит тебя от необходимости прописывать локальные IP-адреса.

🔥 — если за красивые домены и зеленый замочек HTTPS
🤝 — если по старинке открываешь порты в фаерволе и заходишь по IP

➡️ GitHub Ready | #урок

🛡 CrowdSec: Современный щит от ботов и брутфорса

Если твой сервер торчит в интернете, его сканируют боты каждую секунду. Стандартный Fail2Ban хорош, но он работает в одиночку. CrowdSec — это «иммунная система» для твоих контейнеров, которая использует коллективный разум: если IP-адрес атаковал кого-то в сети CrowdSec, он будет забанен и у тебя еще до первой атаки.

Задача:
— Автоматически банить хакеров, сканеров портов и ботов.
— Защитить Nginx Proxy Manager, SSH и другие сервисы без сложных конфигов.
— Использовать постоянно обновляемую базу «плохих» IP со всего мира.

Решение:

Устанавливаем CrowdSec вместе с твоим Reverse Proxy. Он читает логи, находит подозрительную активность и дает команду фаерволу «сбросить» соединение.

Почему это круче старых методов?

— Коллективная безопасность: Как только бот спалился на одном сервере в мире, его данные улетают в общую базу. Твой сервер скачивает этот список и превентивно закрывает дверь.
— Понимает контекст: CrowdSec анализирует не просто факт неудачного входа, а целые сценарии — например, слишком частый перебор URL-адресов или попытки SQL-инъекций.
— Легкая интеграция с Docker: Есть готовые коллекции правил для Docker, Nginx, Traefik и WordPress.
— Удобный дашборд: Ты можешь видеть карту атак на свой сервер и статистику забаненных IP в красивом веб-интерфейсе.

Как это работает?

1. Агент (Agent): Читает логи и обнаруживает угрозу.
2. Баунсер (Bouncer): Исполнитель, который физически блокирует доступ (на уровне фаервола или конфига Nginx).

Совет: В связке с Nginx Proxy Manager используй специальный баунсер (OpenResty), который будет проверять каждый входящий запрос по базе CrowdSec. Это превратит твой входной узел в настоящую цифровую крепость.

🔥 — если веришь в коллективную безопасность
🤝 — если достаточно старого доброго Fail2Ban

➡️ GitHub Ready | #урок

☁️ Cloudflare Tunnels: Как открыть сервер миру без белого IP?

Если у тебя нет выделенного (белого) IP-адреса от провайдера или ты не хочешь возиться с пробросом портов (Port Forwarding), Cloudflare Tunnels — это лучший способ вывести локальные сервисы в интернет. Ты просто запускаешь небольшой агент на сервере, и он сам «прокидывает» мостик до облака Cloudflare.

Задача:
— Опубликовать сайт или сервис из домашней сети/локалки.
— Скрыть реальный IP-адрес своего сервера от атак.
— Забыть о настройке DDNS и дырах в фаерволе роутера.

Как это работает?

Вместо того чтобы ждать входящих подключений, твой сервер сам устанавливает исходящее зашифрованное соединение с ближайшим дата-центром Cloudflare.

Преимущества в 2026 году:

— Безопасность: Тебе не нужно открывать порты на роутере. Весь входящий трафик идет через фильтры Cloudflare, которые отсекают ботов и DDoS-атаки.
— Zero Trust: Ты можешь добавить панель авторизации (через Google, GitHub или почту) поверх своего сервиса всего за пару кликов. Даже если в твоем приложении нет пароля, Cloudflare его добавит.
— Простота: Всё настраивается через удобный веб-интерфейс (Cloudflare Dashboard). Тебе просто нужно скопировать одну команду и запустить её в Docker.
— Бесплатно: Основной функционал туннелей доступен на бесплатном тарифе.

Как запустить через Docker?

При создании туннеля в панели Cloudflare тебе дадут токен. Запуск выглядит так:

docker run -d \
  --name cloudflared \
  --restart unless-stopped \
  cloudflare/cloudflared:latest tunnel --no-autoupdate run --token <ТВОЙ_ТОКЕН>

Кому это нужно?

— Разработчикам, чтобы показать заказчику проект, запущенный прямо на рабочем ноутбуке.
— Владельцам «умных домов» (Home Assistant) для доступа из любой точки мира.
— Тем, чей провайдер выдает только серые IP-адреса (за NAT).

Совет: Используй туннели вместе с Nginx Proxy Manager. Ты можешь направить весь трафик из туннеля на NPM, а он уже сам распределит его по внутренним контейнерам по поддоменам.

🔥 — если за приватность и отсутствие открытых портов
🤝 — если предпочитаешь классический Port Forwarding

➡️ GitHub Ready | #урок

🏠 Homepage: Твоя личная приборная панель для всех сервисов

Когда количество контейнеров переваливает за десяток, помнить все порты и адреса становится невозможно. Вместо закладок в браузере лучше использовать Homepage — современный, быстрый и чертовски красивый дашборд, который собирает все твои ссылки и метрики на одном экране.

Задача:
— Создать единую точку входа для всех локальных и облачных ресурсов.
— Видеть статус сервисов (онлайн/оффлайн) и нагрузку на сервер без перехода в другие вкладки.
— Организовать удобный поиск и группировку инструментов по категориям.

Решение:

Разворачиваем Homepage в Docker. Он настраивается через простые YAML-файлы и выглядит гораздо современнее старых аналогов.



Почему это круто?

— Виджеты с данными: Homepage умеет подключаться к API твоих сервисов. Ты можешь видеть остаток места на диске, скорость загрузки в Transmission, количество активных клиентов в AdGuard Home или текущую погоду прямо на иконках.
— Статистика сервера: Сверху всегда отображается загрузка CPU, оперативной памяти и состояние сети.
— Полная кастомизация: Можно менять фоны, иконки, цвета и структуру групп. Всё работает мгновенно благодаря статической генерации.
— Docker-интеграция: Он может сам «подтягивать» информацию о запущенных контейнерах через сокет, показывая их статус в реальном времени.

Как запустить?

# docker-compose.yml
services:
  homepage:
    image: ghcr.io/gethomepage/homepage:latest
    ports:
      - 3000:3000
    volumes:
      - ./config:/app/config # Здесь лежат твои YAML настройки
      - /var/run/docker.sock:/var/run/docker.sock # Для получения статуса контейнеров

Кому это нужно?

— Владельцам домашних лабораторий (Homelab).
— Разработчикам, которые хотят иметь быстрый доступ к мониторингу, логам и стейджингу на одной странице.
— Всем, кто ценит эстетику в рабочем пространстве.

Совет: Используй встроенный поиск по странице (клавиша /), чтобы мгновенно находить нужный сервис среди десятков ссылок. Это экономит уйму времени, когда проект разрастается.

🔥 — если любишь, когда всё красиво и под рукой
🤝 — если достаточно стандартной страницы «Новая вкладка»

➡️ GitHub Ready | #урок

🛠 AdGuard Home: Чистый интернет без рекламы и трекеров

Если тебе надоело вырезать баннеры в каждом браузере отдельно, пора переходить на сетевой уровень. AdGuard Home — это мощный DNS-сервер, который блокирует рекламу и слежку на всех устройствах сразу: от твоего рабочего ноутбука до умного телевизора и смартфонов.

Задача:
— Убрать рекламу во всех приложениях и браузерах.
— Запретить устройствам «стучать» своим производителям (телеметрия).
— Ускорить загрузку страниц за счет того, что мусорный контент даже не начинает скачиваться.

Решение:

Устанавливаем AdGuard Home в Docker и направляем трафик роутера через него.



Почему это маст-хэв?

— Блокировка на уровне DNS: Реклама фильтруется до того, как попадет на устройство. Это экономит трафик и заряд батареи на мобилках.
— Родительский контроль: Можно в один клик запретить доступ к сайтам для взрослых или ограничить использование YouTube и соцсетей по расписанию.
— Шифрование трафика: Поддержка DNS-over-HTTPS (DoH) и DNS-over-TLS (DoT) защищает твои запросы от провайдера и злоумышленников.
— Статистика: Ты увидишь реальную картину того, какие устройства и куда пытаются ломиться в сети.

Как запустить?

# docker-compose.yml
services:
  adguardhome:
    image: adguard/adguardhome
    container_name: adguardhome
    restart: unless-stopped
    volumes:
      - ./workdir:/opt/adguardhome/work
      - ./confdir:/opt/adguardhome/conf
    ports:
      - "53:53/tcp"
      - "53:53/udp"
      - "80:80/tcp"
      - "3000:3000/tcp" # Первичная настройка
      - "443:443/tcp"

Кому это нужно?

— Семьям, чтобы защитить детей от нежелательного контента.
— Энтузиастам, которые хотят превратить свой домашний сервер в центр управления безопасностью.
— Всем, кого бесит реклама, встроенная прямо в интерфейс Smart TV.

Совет: После запуска пропиши IP-адрес своего сервера в настройках DNS на роутере. Теперь все устройства, подключающиеся к твоему Wi-Fi, автоматически получат «чистый» интернет без единой дополнительной настройки.


🔥 — если за интернет без баннеров и слежки
🤝 — если привык к рекламе и просто её не замечаешь

➡️ GitHub Ready | #урок

📁 FileBrowser: Твой личный Google Drive на собственном сервере

Если тебе нужно быстро скинуть файл на сервер или скачать логи без использования терминала и SCP, ставь FileBrowser. Это легковесный и быстрый веб-менеджер файлов, который превращает любую папку на твоем диске в удобный интерфейс, доступный через браузер.

Задача:
— Управлять файлами на сервере через графический интерфейс.
— Иметь возможность создавать публичные ссылки на файлы для друзей или коллег.
— Редактировать конфиги или просматривать картинки/видео прямо в браузере.

Решение:

Запускаем контейнер, пробрасываем в него нужную директорию и получаем полноценный проводник.



Почему это удобно?

— Легкость: Весь сервис — это один бинарный файл. Он потребляет копейки оперативной памяти и работает мгновенно.
— Управление пользователями: Можно создать аккаунты для разных людей, ограничив их только определенными папками (например, только папкой /uploads).
— Встроенный редактор: Ты можешь править .env файлы, YAML-конфиги или скрипты прямо в браузере с подсветкой синтаксиса.
— Shell-команды: Прямо из интерфейса можно запускать команды (например, распаковать архив или создать папку), если у пользователя есть права.

Как запустить?

# docker-compose.yml
services:
  filebrowser:
    image: filebrowser/filebrowser:latest
    ports:
      - 8080:80
    volumes:
      - /path/to/your/files:/srv # Твои файлы здесь
      - ./database.db:/database.db
      - ./settings.json:/config/settings.json
    restart: unless-stopped

Кому это нужно?

— Разработчикам для удобного доступа к артефактам сборки или логам.
— Тем, кто хочет поднять свое «облако» для хранения личных документов и фото без подписок.
— Владельцам серверов, которым лень каждый раз вводить ssh и ls -la для простых операций.

Совет: В настройках можно включить генерацию превью для изображений и видео. Это превратит твой сервер в удобную галерею, где можно быстро найти нужный скриншот или ролик.

🔥 — если за удобный UI в управлении сервером
🤝 — если терминал — твой единственный файловый менеджер

➡️ GitHub Ready | #урок

📂 Простой обменник файлов между устройствами

MicroBin — безопасное, опенсорсное и настраиваемое веб-приложение для обмена файлами и сокращения URL-адресов, написанное на Rust.

👉 Особенности: шифрование на стороне сервера и клиента, поддержка QR-кодов, поддержка SQLite и JSON, автоудаление контента и многое другое.

Клик!

➡️ GitHub Ready | #урок