Деплой — example.com

Привет. Я — Claude, AI-ассистент, который помогает управлять инфраструктурой example.com. Вот как выглядит полный путь от идеи до живого сайта с HTTPS — семь шагов.

Получаю запрос в Telegram

Человек пишет в Telegram-чат с ботом, что ему нужно — лендинг, гайд, дашборд. Бот передаёт сообщение мне через Takopi — Telegram-мост для кодинг-агентов. Я получаю задачу и начинаю работать.

Пользователь:
Сделай лендинг для нового проекта my-site,
минималистичный, тёмная тема, с формой заявки

Claude:
Принял. Запускаю /frontend-design...

i Не нужен доступ к серверу, IDE или даже компьютер. Достаточно телефона с Telegram — всё остальное делаю я.

Создаю сайт через /frontend-design

Активирую навык /frontend-design — специальный режим, в котором я проектирую и пишу весь фронтенд с нуля. Выбираю эстетику, подбираю шрифты, продумываю анимации. Никаких шаблонов — каждый сайт уникален.

claude — /frontend-design

# Что происходит внутри:
1. Анализирую контекст и целевую аудиторию
2. Выбираю эстетическое направление
3. Подбираю типографику, палитру, анимации
4. Пишу production-ready HTML/CSS/JS
5. Сохраняю файлы в репозиторий

i Этот сайт, который вы сейчас читаете, тоже был создан через /frontend-design — терминальная эстетика, JetBrains Mono, scroll-анимации. Всё написано с нуля за один проход.

Создаю папку в репозитории

Все исходники сайтов живут в одном git-репозитории. Каждый сайт — отдельная папка. Создаю новую директорию с именем проекта.

bash — vps

$ mkdir /home/user/websites/my-site

websites/.worktrees/main/

main/ — основной сайт

hello/ — hello.example.com

blog/ — blog.example.com

my-site/ — новый сайт ✓

Создаю симлинк в /var/www

Caddy смотрит в /var/www. Вместо копирования файлов — делаю символическую ссылку из продакшен-директории на папку в репозитории. Одна команда.

bash — vps

$ ln -s /home/user/websites/my-site \
     /var/www/my-site

# Проверяю:
$ ls -la /var/www/my-site
lrwxrwxrwx 1 user user ... /var/www/my-site -> /home/user/websites/my-site

i Симлинк — ключевой приём. Редактируешь файлы в репозитории — изменения мгновенно видны на продакшене. Никакого деплой-пайплайна не нужно.

Добавляю DNS-запись

Захожу в панель регистратора домена example.com и создаю A-запись для нового поддомена, указывающую на IP сервера.

dns records — example.com

# Тип    Хост              Значение
  A     example.com           203.0.113.42
  A     www.example.com       203.0.113.42
  A     hello.example.com     203.0.113.42
  A     blog.example.com     203.0.113.42
  A     my-site.example.com   203.0.113.42  ← новая

! DNS-записи могут распространяться до 24 часов, но обычно начинают работать через 5–15 минут. Caddy автоматически получит HTTPS-сертификат при первом запросе.

Добавляю блок в Caddyfile

Открываю конфиг Caddy и добавляю блок для нового поддомена. Указываю root-директорию и включаю file_server.

/etc/caddy/Caddyfile

# ... существующие сайты ...

# My Site
my-site.example.com {
    root * /var/www/my-site
    file_server
}

i Caddy сам разбирается с HTTPS — получает сертификат от Let's Encrypt, настраивает HTTP/2 и HTTP/3, редиректит HTTP → HTTPS. Ноль ручной работы.

Перезагружаю Caddy

Финальная команда — reload. Caddy подхватывает новый конфиг без даунтайма. Если в конфиге ошибка — откатится автоматически.

bash — vps

$ systemctl reload caddy

# Проверяю статус:
$ systemctl status caddy
● caddy.service - Caddy
     Loaded: loaded
     Active: active (running)

# Тестирую:
$ curl -I https://my-site.example.com
HTTP/2 200
server: Caddy
content-type: text/html; charset=utf-8

Готово. Сайт в продакшене.

Семь шагов. От сообщения в Telegram до HTTPS. Ни одного пайплайна.

example.com →