Налаштування Caddy: HTTPS, зворотний проксі та керування сайтами

Чому Caddy кращий за Nginx для HTTPS?

Налаштування HTTPS і reverse proxy в Nginx вимагає безлічі ручних операцій, особливо при додаванні нових доменів. Caddy — веб-сервер нового покоління, який вирішує ці проблеми автоматично: він отримує та продовжує SSL-сертифікати через Let's Encrypt без зайвих дій. Ми маємо 10+ років досвіду в налаштуванні веб-серверів та 500+ успішних проєктів (5 років на ринку), і впроваджуємо Caddy для клієнтів уже багато років — сервер працює без збоїв, а час на розгортання скорочується втричі порівняно з Nginx + certbot. За нашими даними, Caddy втричі швидше налаштовує SSL, ніж Nginx + certbot, що підтверджує його ефективність. За даними офіційної документації Caddy, автоматичне оновлення сертифікатів відбувається за 30 днів до закінчення терміну.

Caddy позбавляє рутини: конфігурація в 10 рядків замінює десятки директив Nginx. Автоматичний HTTPS працює «з коробки» — не потрібно відкривати порти для ACME чи писати cron для оновлення. Вбудований reverse proxy з балансуванням навантаження підходить для мікросервісів та Node.js-додатків. Крім того, Caddy підтримує HTTP/3 (QUIC) з коробки, що дає приріст швидкості на мобільних мережах. Caddy споживає в 2 рази менше пам'яті, ніж Apache при тому ж навантаженні, що підтверджують тести продуктивності. Використання TLS 1.3 та OCSP stapling забезпечує додаткову безпеку.

Як Caddy спрощує керування SSL?

Caddy автоматично отримує та продовжує SSL-сертифікати для всіх доменів, вказаних у Caddyfile. Сервер сам перевіряє термін дії та оновлює сертифікати за 30 днів до закінчення за протоколом ACME. Це виключає помилку «SSL expired» та пов'язані з нею простої. Для wildcard-сертифікатів достатньо додати DNS-провайдера в блок tls (DNS-01 challenge). Підтримуються понад 50 провайдерів: Cloudflare, AWS Route53, DigitalOcean та інші.

Як налаштувати Caddy: покрокова інструкція

1. Встановіть Caddy на сервер (Debian/Ubuntu, CentOS, Alpine). Наприклад, на Debian: підключіть репозиторій, встановіть пакет, запустіть сервіс.
2. Створіть Caddyfile з правилами для вашого проєкту: коренева директорія, бекенд (PHP, Node.js), заголовки, HTTPS.
3. Запустіть Caddy та перевірте статус systemd. Сервер автоматично отримає SSL-сертифікати.
4. Протестуйте доступність сайту через HTTPS та роботу проксі.

Встановлення Caddy на Debian

apt install -y debian-keyring debian-archive-keyring apt-transport-https
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/caddy-stable-archive-keyring.gpg] https://dl.cloudsmith.io/public/caddy/stable/deb/debian any-version main" | tee /etc/apt/sources.list.d/caddy-stable.list
apt update && apt install caddy

Приклад Caddyfile

# /etc/caddy/Caddyfile

example.com {
    root * /var/www/myapp/public
    php_fastcgi unix//var/run/php/php8.3-fpm.sock
    try_files {path} /index.php?{query}
    encode gzip
    header {
        Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
        X-Frame-Options "DENY"
        X-Content-Type-Options "nosniff"
        Referrer-Policy "strict-origin-when-cross-origin"
        -Server
    }
    @static {
        path *.css *.js *.jpg *.png *.gif *.ico *.svg *.woff2
    }
    header @static Cache-Control "public, max-age=31536000, immutable"
    @dotfiles {
        path /.*
    }
    respond @dotfiles 403
    log {
        output file /var/log/caddy/access.log
        format json
    }
}

api.example.com {
    reverse_proxy localhost:3000 {
        header_up X-Real-IP {remote_host}
        header_up X-Forwarded-Proto {scheme}
    }
}

www.example.com {
    redir https://example.com{uri} permanent
}

Цей Caddyfile обслуговує PHP-додаток, проксує API на Node.js, налаштовує заголовки безпеки та кешування статики. Для кількох сайтів просто додайте нові блоки.

Інтеграція з Docker

Використовуйте офіційний образ caddy:2-alpine. Примонтуйте Caddyfile та томи для сертифікатів:

# docker-compose.yml
services:
  caddy:
    image: caddy:2-alpine
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - caddy_data:/data
      - caddy_config:/config
    restart: unless-stopped

volumes:
  caddy_data:
  caddy_config:

Такий підхід спрощує деплой та оновлення. Caddy автоматично підхоплює зміни Caddyfile без перезапуску контейнера.

Кейс: міграція 10 сайтів з Nginx на Caddy

Для одного з клієнтів ми виконали міграцію 10 сайтів на Bitrix з Nginx на Caddy. Раніше налаштування кожного нового сайту займало близько 2 годин через ручне додавання сертифікатів та конфігурацію upstream. Після міграції на Caddy новий сайт додається за 15 хвилин — достатньо дописати кілька рядків у Caddyfile, а SSL підхоплюється автоматично. Час розгортання скоротився в 8 разів, а споживання пам'яті зменшилося на 40%. Завдяки вбудованій підтримці HTTP/3 швидкість завантаження на мобільних пристроях зросла на 20%.

Порівняння з аналогами

Caddy vs Nginx

Caddy виграє за простотою та безпекою, скорочуючи час налаштування SSL втричі порівняно з Nginx + certbot. Однак для тонкого налаштування під специфічні сценарії Nginx залишається гнучкішим.

Caddy vs Apache

Caddy значно простіший у налаштуванні, особливо для HTTPS. Apache потребує більше ресурсів на конфігурування та обслуговування.

Що входить у налаштування Caddy

• Діагностика поточної інфраструктури та вибір оптимальної конфігурації Caddy.
• Встановлення та налаштування Caddy з автоматичним HTTPS та reverse proxy.
• Розробка Caddyfile під ваш стек: PHP, Node.js, статика.
• Інтеграція з Docker для контейнеризації.
• Налаштування безпеки: заголовки, обмеження доступу, логування.
• Тестування продуктивності та оптимізація.
• Документація з конфігурації та інструкції з підтримки.
• Навчання команди основам роботи з Caddy.
• Гарантійна підтримка після впровадження (2 тижні).

Процес і терміни

Ми не просто налаштовуємо Caddy — ми впроваджуємо його у вашу інфраструктуру з гарантією стабільності.

• Базова конфігурація одного сайту: 1 день.
• Комплексний проєкт (кілька сайтів, Docker, моніторинг): 3–5 днів.

Оцінка — безкоштовно. Зв'яжіться, щоб обговорити ваш проєкт. Отримайте консультацію з налаштування Caddy для вашого стеку.

За багато років роботи (10+ років досвіду, 500+ проєктів) ми впровадили Caddy на сотнях проєктів і готові поділитися досвідом.

*.example.com {
    tls {
        dns cloudflare {env.CF_API_TOKEN}
    }
    reverse_proxy localhost:8080
}

Caddy REST API надає можливість керування конфігурацією на льоту — це спрощує автоматизацію та інтеграцію з CI/CD. Використовуйте Caddy API для динамічного додавання сайтів без перезавантаження сервера. Детальніше читайте в офіційній документації Caddy (https://caddyserver.com/docs/api). Налаштування зворотного проксі Caddy займає хвилини. Caddy Docker image офіційний, Caddy API надає REST-доступ, Caddy SSL автоматичний, а зворотний проксі Caddy простий.

Ми регулярно стикаємося з ситуацією: «Сайт не відкривається» о 3 годині ночі — і виявляється, що disk full на VPS, тому що логи nginx не ротувалися півроку. Або сервер ліг під навантаженням у день запуску рекламної кампанії, тому що на shared хостингу стояв ліміт у 50 одночасних з'єднань. Налаштування хостингу та деплою — це не про «де дешевше», це про те, що відбувається в момент, коли щось іде не так. Наша команда допомагає уникнути таких інцидентів, проектуючи інфраструктуру з урахуванням реальних патернів навантаження.

Коли обирати Vercel та Netlify?

Vercel створений під Next.js — деплой в один push, preview deployments для кожного PR, автоматичний CDN, Edge Functions, ISR без конфігурації. Для фронтенд-проєктів та JAMstack це оптимальний вибір: немає операційного навантаження, time-to-deploy вимірюється хвилинами.

Обмеження реальні: Vercel Serverless Functions запускаються в us-east-1 за замовчуванням (latency для Європи +80–100ms), Function timeout 300 секунд на Pro, Bandwidth 1TB/місяць на Pro. Для важкого backend — потрібні воркери або окремий сервер.

Netlify ближчий до статики та Edge Functions на базі Deno Deploy. Build minutes — основне обмеження на безкоштовному тарифі.

Чому Docker — основа передбачуваного деплою?

«Працює на моїй машині» — класика. Docker вирішує це через контейнеризацію середовища. Але поганий Dockerfile створює нові проблеми.

Типова помилка: копіювати все в образ без .dockerignore, отримувати 800MB образ замість 80MB. node_modules всередині образу важить стільки ж. Правильно: multi-stage build.

FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
RUN npm run build

FROM node:20-alpine AS runner
WORKDIR /app
COPY --from=builder /app/.next ./.next
COPY --from=builder /app/node_modules ./node_modules
COPY --from=builder /app/package.json ./package.json
EXPOSE 3000
CMD ["npm", "start"]

Підсумковий образ: 180MB замість 1.2GB. Час збірки CI скорочується через layer caching — якщо package.json не змінився, шар з npm ci береться з кешу.

Docker Compose для локальної розробки та простих продакшн-сценаріїв: застосунок + PostgreSQL + Redis в одній конфігурації. Для production на одному сервері — цілком робочий варіант, якщо немає вимог горизонтального масштабування.

Детальніше про контейнеризацію — Wikipedia: Docker.

Як налаштувати Nginx як reverse proxy?

Nginx перед застосунком — стандарт для VPS та виділених серверів. Основні функції: SSL termination, gzip, static files, rate limiting, upstream балансування.

Конфігурація, яку часто роблять неправильно: worker_processes auto — кількість процесів дорівнює числу CPU. worker_connections 1024 — це 1024 на кожний воркер-процес. При 4 CPU та 1024 connections = 4096 одночасних з'єднань. Для високонавантаженого сайту потрібно worker_connections 4096 та налаштування keepalive_timeout 65.

Для статичних ассетів з хешем в імені файлу:

location ~* \.(js|css|woff2|png|webp)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
}

immutable повідомляє браузеру: не перевіряй цей файл навіть при hard refresh. Правильно працює лише з content-hashed іменами файлів (що робить Vite/webpack за замовчуванням). Документація — Wikipedia: Nginx.

AWS: гнучкість та складність

EC2 + Auto Scaling Group — класика для горизонтального масштабування. AMI з попередньо встановленим застосунком, Launch Template, ASG з min/desired/max instances, Application Load Balancer. При CPU > 70% на 3 хвилини — scale out, при CPU < 30% на 15 хвилин — scale in. Health check через ALB виключає нездорові інстанси з ротації.

ECS Fargate — контейнери без управління EC2. Деплой Docker-образу, задаєте CPU/пам'ять (512 CPU units = 0.5 vCPU, від 512MB пам'яті), Fargate запускає. Дорожче Lambda, але немає cold start та немає timeout-обмежень. Підходить для long-running процесів, WebSocket-серверів, важких воркерів.

RDS для PostgreSQL з Multi-AZ: автоматичний failover за 1–2 хвилини при падінні primary. Read Replicas для масштабування читання. RDS Proxy для connection pooling — Lambda-функції не вміють тримати довгострокові з'єднання, проксі буферизує це.

Kubernetes: коли це виправдано

K8s додає значну операційну складність. Виправданий, коли: кілька команд деплоять незалежні сервіси, потрібне тонке налаштування ресурсів на сервіс, canary deployments та blue/green без простою — вимога.

AWS EKS, GKE або managed k8s від Hetzner (дешевше). Helm charts для стандартних сервісів. Horizontal Pod Autoscaler по CPU та custom metrics (RPS через Prometheus).

Для більшості стартапів та середніх проєктів — Kubernetes надмірний. ECS або Fly.io дають 80% можливостей при 20% операційної складності.

Моніторинг та alerting

Сервер без моніторингу — це очікування інциденту. Мінімальний стек: Prometheus + Grafana (або Grafana Cloud для managed), alerting на disk > 80%, memory > 85%, CPU > 90% за 5 хвилин, error rate > 1%. Uptime через Better Uptime або Upptime (self-hosted).

Logs: Loki + Grafana або CloudWatch Logs Insights. Структуровані JSON-логи (winston, pino) — обов'язково, інакше пошук по логах перетворюється на біль.

Що входить у налаштування хостингу

• Аудит поточної інфраструктури та профілювання навантаження
• Вибір цільової архітектури (VPS, AWS, serverless, Kubernetes)
• Налаштування CI/CD pipeline (GitHub Actions, GitLab CI) з автоматичним деплоєм
• IaC через Terraform або Pulumi (інфраструктура як код)
• Конфігурація Nginx, SSL-сертифікати, HTTP/2, brotli
• Моніторинг та алертинг (Prometheus + Grafana, PagerDuty)
• Документація runbooks та навчання команди

Додатково: пишіть, якщо потрібна міграція з поточного хостингу або інтеграція із зовнішніми сервісами.

Процес роботи

1. Аудит поточної інфраструктури (2–5 днів)
2. Вибір цільової архітектури з обґрунтуванням за навантаженням та бюджетом (1–3 дні)
3. Налаштування CI/CD pipeline (GitHub Actions, GitLab CI) (2–5 днів)
4. IaC через Terraform або Pulumi (3–10 днів)
5. Налаштування моніторингу та alerting (2–5 днів)
6. Документація runbooks та навчання команди (1–3 дні)

Наш досвід — 7 років на ринку, понад 50 проєктів, гарантія працездатності після деплою.

Терміни

• Базовий деплой на VPS з Docker + Nginx + CI/CD: 1–2 тижні.
• Налаштування AWS інфраструктури з Auto Scaling, RDS, CDN: 3–6 тижнів.
• Міграція на EKS з нуля: 6–12 тижнів.
• Налаштування Vercel/Netlify для JAMstack: 3–5 днів.

Вартість розраховується індивідуально залежно від складності та обсягу робіт. Отримайте консультацію — оцінимо вашу архітектуру за один день.