TimeWeb, Selectel, Beget и Yandex Cloud — выбор VPS и развёртывание

Практическое руководство по выбору и развёртыванию виртуального сервера (VPS) в России: как оценить тариф и подготовить чистый сервер к размещению рабочих сервисов.

Оглавление

1. Что такое облачный VPS: доступные компоненты и варианты создания.
2. Когда нужен российский VPS: данные, оплата, задержка и интеграции.
3. Провайдеры: критерии сравнения и место Timeweb Cloud.
4. Тарифы и конфигурация: CPU, RAM, диск, регионы и цены.
5. Создание сервера и SSH: безопасный вход и базовая защита.
6. Системные настройки: swap, часовой пояс и обновления.
7. Caddy и HTTPS: домен, обратный прокси и сертификат.
8. IPv4, IPv6 и NAT: когда нужен публичный адрес.
9. Docker: установка и публикация портов.
10. Деплой Astro и Worker-приложений: варианты запуска и проверка.
11. Полезные сценарии: три типовых архитектуры.
12. Резервное копирование и мониторинг: бэкапы, снапшоты и контроль состояния.
13. Автоматизация через API: API, CLI, Terraform и cloud-init.
14. Проверка результата: команды перед подачей трафика.
15. Чеклист развёртывания: финальная проверка.

Что такое облачный VPS

Облачный VPS — виртуальный сервер с выбранными вычислительными ресурсами, диском, операционной системой и сетевыми настройками. Вы самостоятельно управляете ОС и сервисами, поэтому вместе с гибкостью получаете ответственность за обновления, доступы, firewall и резервное копирование.

В Timeweb Cloud при создании сервера можно выбрать ОС или готовый образ, регион и зону доступности, фиксированную или произвольную конфигурацию, публичный IPv4, IPv6, приватную сеть, SSH-ключ, cloud-init и параметры резервного копирования. Сервер можно создать в панели либо автоматизировать через API, CLI и Terraform.

Когда нужен российский VPS

Российский сервер полезен в нескольких сценариях:

• Оплата рублями. Timeweb Cloud принимает банковские переводы, российские и зарубежные карты, а также ЮMoney.
• Персональные данные. Если сервис обрабатывает персональные данные россиян, заранее проверьте требования 152-ФЗ к локализации и архитектуре хранения. Для юридически значимого решения потребуется разбор конкретного процесса обработки данных.
• Низкая задержка для российской аудитории. Локацию лучше выбирать после проверки пинга из сетей ваших пользователей.
• Интеграции, которым нужен российский IP. Ограничения по геолокации зависят от конкретного внешнего сервиса и должны проверяться отдельно.

Провайдеры: как сравнить Timeweb Cloud, Selectel, Beget и Yandex Cloud

Провайдеров стоит сравнивать по доступным регионам, сетевой архитектуре, резервному копированию, автоматизации и полной стоимости всех компонентов.

Для небольшого проекта Timeweb Cloud остаётся понятной отправной точкой. Перед окончательным выбором соберите одинаковую конфигурацию у нескольких провайдеров и сравните полную месячную стоимость, включая IP, бэкапы и защиту от атак.

Тарифы Timeweb Cloud и выбор конфигурации

Для небольшого сайта, бота или API обычно разумно начинать с двух процессорных ядер и 2–4 ГБ RAM. Один гигабайт памяти быстро становится ограничением для Docker, Node.js и локальной базы данных.

Фиксированные тарифы Premium 3.3 ГГц в Москве на 9 сентября 2026 года:

На витрине указаны скидки 5% при оплате за 3 месяца, 7% за 6 месяцев и 10% за 12 месяцев. Доступность тарифных линеек зависит от региона. В документации перечислены Premium NVMe, Ultra, GPU, Standard, HighCPU, Dedicated CPU и Dedicated High CPU.

Timeweb Cloud указывает локации в Москве, Санкт-Петербурге, Новосибирске, Алматы, Амстердаме и Франкфурте; на тарифной витрине также доступен Нью-Йорк. Набор регионов и конфигураций меняется, поэтому проверяйте его непосредственно перед созданием сервера.

Бесплатное тестирование возможно по индивидуальному запросу: провайдер рассматривает заявки отдельно. Это не гарантированный пробный период для каждого нового аккаунта.

Создание сервера и безопасный вход по SSH

При создании сервера выберите чистую ОС, регион, конфигурацию и сеть. Timeweb Cloud позволяет добавить SSH-ключ, отключить вход по root-паролю и передать сценарий cloud-init. Создание также можно автоматизировать через Terraform, CLI или API.

Ниже приведён сценарий для Ubuntu. В другой ОС названия пакетов, пути и команды могут отличаться.

1. Обновите систему и создайте рабочего пользователя. Команды выполняйте под root или через sudo.

apt update && apt upgrade -y
adduser deploy
usermod -aG sudo deploy

# Если нужный публичный ключ уже находится в authorized_keys пользователя root:
install -d -m 700 -o deploy -g deploy /home/deploy/.ssh
install -m 600 -o deploy -g deploy /root/.ssh/authorized_keys /home/deploy/.ssh/authorized_keys

Копируйте только файл authorized_keys, а не весь каталог /root/.ssh: в нём могут находиться приватные ключи. Если парольная авторизация для deploy временно разрешена, вместо копирования файла можно выполнить в отдельном локальном терминале ssh-copy-id deploy@SERVER_IP.

2. Проверьте вход новым пользователем в отдельном терминале. Только после успешной проверки отключайте root-вход и парольную авторизацию.

В /etc/ssh/sshd_config или применяемом дополнительном конфигурационном файле (drop-in) должны быть заданы:

PermitRootLogin no           # запретить вход root
PasswordAuthentication no    # запретить вход по паролю
PubkeyAuthentication yes     # разрешить вход по ключу

Сначала найдите файл, который задаёт итоговое значение, затем проверьте конфигурацию:

grep -RniE '^(PermitRootLogin|PasswordAuthentication|PubkeyAuthentication)' /etc/ssh/sshd_config /etc/ssh/sshd_config.d
sshd -t
sshd -T | grep -E 'permitrootlogin|passwordauthentication|pubkeyauthentication'
systemctl reload ssh

3. Включите firewall.

apt install ufw -y
ufw default deny incoming
ufw default allow outgoing
ufw allow OpenSSH
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable
ufw status verbose

Если SSH слушает нестандартный порт, откройте его вместо профиля OpenSSH до включения UFW.

4. Установите fail2ban.

apt install fail2ban -y
install -d /etc/fail2ban/jail.d
printf '%s\n' '[sshd]' 'enabled = true' | tee /etc/fail2ban/jail.d/sshd.local >/dev/null
systemctl enable --now fail2ban
fail2ban-client version
fail2ban-client status sshd

Свои настройки храните в /etc/fail2ban/jail.local или в отдельном файле /etc/fail2ban/jail.d/, чтобы обновление пакета не затёрло их.

Swap, часовой пояс и обновления безопасности

На сервере с 1–2 ГБ RAM swap снижает риск немедленного завершения процессов при кратковременном пике памяти:

fallocate -l 2G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile
echo '/swapfile none swap sw 0 0' >> /etc/fstab
swapon --show

Строку в /etc/fstab добавляйте один раз. Swap работает медленнее RAM и не заменяет увеличение памяти при постоянной нагрузке.

Если задачи и журналы должны соответствовать московскому времени:

timedatectl set-timezone Europe/Moscow
timedatectl status

Для автоматической установки исправлений безопасности:

apt install unattended-upgrades -y
dpkg-reconfigure --priority=low unattended-upgrades

Caddy, домен и HTTPS

Caddy удобен для небольшого проекта благодаря автоматическому получению и продлению TLS-сертификатов. Ниже предполагается, что Caddy уже установлен.

Статический сайт:

example.ru {
    encode gzip                  # сжатие ответа
    root * /var/www/example      # каталог со статическими файлами
    file_server                   # отдача файлов
}

Приложение на локальном порту:

api.example.ru {
    reverse_proxy 127.0.0.1:3000 # локальное приложение
}

Создайте DNS-запись A, указывающую на публичный IPv4 сервера. После запуска проверьте конфигурацию, HTTPS и ответ приложения:

caddy validate --config /etc/caddy/Caddyfile --adapter caddyfile
systemctl status caddy
curl -I https://example.ru

Если домен проксируется через Cloudflare, используйте корректный сертификат на origin-сервере и режим SSL/TLS Full (strict).

Когда нужен собственный IPv4, а когда достаточно NAT

Публичный IPv4 Timeweb Cloud можно переносить между сервисами внутри одного региона. Он позволяет сервису принимать запросы из интернета и выходить во внешнюю сеть.

Собственный IPv4 нужен, если сервер должен быть доступен напрямую из интернета или ему требуется отдельный исходящий адрес. Есть исключения:

• сервис работает только в приватной сети;
• несколько сервисов выходят в интернет через общий публичный IPv4, привязанный к приватной сети с трансляцией сетевых адресов (NAT);
• входящий трафик принимает отдельный балансировщик или другой сетевой компонент.

Сервисы в приватной сети могут выходить в интернет через общий адрес с NAT, если для них настроено правило маршрутизации «Только исходящий».

Бесплатный IPv6 доступен только в части регионов. Он менее универсален: возможность подключения зависит и от сети пользователя. Перед отказом от IPv4 проверьте все внешние API и каналы администрирования из реальных клиентских сетей.

Docker без случайно открытых портов

Установите Docker из официального apt-репозитория для Ubuntu:

apt install ca-certificates curl -y
install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
chmod a+r /etc/apt/keyrings/docker.asc

echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo $VERSION_CODENAME) stable" > /etc/apt/sources.list.d/docker.list

apt update
apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin -y
usermod -aG docker deploy

После повторного входа пользователя проверьте установку:

docker version
docker compose version
docker run --rm hello-world

Сервисы запускаются командой:

docker compose up -d
docker compose ps
docker compose logs --tail=100

Для долгоживущих контейнеров задайте restart: unless-stopped и после перезагрузки проверьте, что стек поднялся автоматически.

Деплой Astro и Worker-приложений

Статический сайт Astro можно собрать и скопировать в каталог, который отдаёт Caddy. Команды выполняйте в каталоге проекта:

npm ci
npm run build
rsync -a --delete ./dist/ /var/www/example/

Флаг --delete удаляет из каталога назначения файлы, которых нет в dist. Если там хранятся другие данные, уберите этот флаг или используйте отдельный каталог.

Проверьте наличие файлов и публичный ответ:

ls -la /var/www/example
curl -I https://example.ru

Приложения для Cloudflare Workers нельзя автоматически считать обычными Node.js-приложениями: используемые API могут зависеть от среды выполнения Worker (runtime). Возможны два пути:

• запуск в совместимой среде выполнения, например workerd, если проект и его зависимости поддерживаются;
• адаптация под Node.js, если используемые API поддерживаются выбранным адаптером.

Долгоживущий процесс держите под systemd, менеджером процессов или в контейнере с политикой перезапуска.

flowchart LR
    A["Git push"] --> B["Сборка"]
    B --> C{"Тип проекта"}
    C -->|"Статика"| D["Каталог /var/www"]
    C -->|"API или Worker"| E["Совместимый runtime"]
    D --> F["Caddy и HTTPS"]
    E --> F
    F --> G["Пользователь"]

Полезные сценарии

Небольшой сайт или бот

Создайте MSK 40 или сопоставимую конфигурацию, добавьте IPv4, настройте SSH-ключ, UFW, Caddy и внешний мониторинг. Результат проверяется входом по ключу, выводом ufw status, успешным HTTPS-запросом и уведомлением тестового монитора.

Ограничение: 2 ГБ RAM могут закончиться при локальной сборке фронтенда, одновременном запуске нескольких контейнеров или базы данных.

API с базой данных

Разместите API и базу в Docker, публикуйте порт базы только на 127.0.0.1, а HTTP(S)-доступ к API организуйте через Caddy. Настройте отдельные дампы базы и копирование за пределы сервера.

Результат: API отвечает по HTTPS, порт базы недоступен снаружи, дамп создаётся по расписанию и успешно восстанавливается в тестовое окружение.

Несколько серверов в приватной сети

Создайте сервисы в совместимом регионе и тарифной линейке, объедините их приватной сетью и используйте общий публичный адрес с NAT для исходящих подключений, если отдельные IP не требуются. Для сервисов должна быть настроена маршрутизация «Только исходящий».

Результат: сервисы обмениваются данными по приватным адресам, а исходящие соединения проходят через общий шлюз. Доступность приватных сетей зависит от региона и линейки сервера.

Резервное копирование и мониторинг

Timeweb Cloud предлагает бэкапы, снапшоты и аварийные копии.

• Бэкап — полная копия отдельного диска, размещённая на отдельном сервере. На 9 сентября 2026 года стоимость размещения составляет 6 ₽ за 1 ГБ диска для каждой существующей копии. Оплата списывается за каждый существующий бэкап, даже если новые копии больше не создаются.
• Снапшот — бесплатная точка быстрого отката всего сервера. Можно создать один снапшот на сервер; он хранится 7 дней.
• Аварийная копия — дополнительная опция для Москвы и Санкт-Петербурга за 200 ₽/мес. Копия создаётся не реже одного раза в пять дней, а восстановление выполняет поддержка.

Перед восстановлением полной копии провайдер рекомендует выключить сервер. Операция вернёт состояние диска к моменту создания выбранной копии, а текущие файлы и конфигурации будут заменены.

Для базы данных делайте согласованные дампы pg_dump или mysqldump, храните копию вне VPS и регулярно проверяйте восстановление.

Минимальный мониторинг включает:

• внешнюю проверку HTTPS;
• алерт при заполнении диска;
• контроль памяти и перезапусков контейнеров;
• проверку возраста последнего бэкапа и дампа;
• журналирование Caddy и приложений.

Заведите серверный паспорт: провайдер, тариф, IP, ОС, домены, сервисы, порты, расположение бэкапов, дата создания и ответственный.

Автоматизация через API, CLI, Terraform и cloud-init

Timeweb Cloud официально поддерживает API, CLI, Terraform и cloud-init. Через них можно воспроизводимо создавать серверы и передавать стартовую конфигурацию.

Официальная точка входа в справочник: документация публичного API.

Начинайте автоматизацию с инвентаризации и проверочных запросов. Изменяющие и удаляющие операции выполняйте отдельными согласованными шагами. API показывает облачные ресурсы, но состояние приложений внутри VPS придётся проверять через SSH, систему мониторинга или агент управления.

Проверка результата после развёртывания

Перед подачей трафика выполните короткую проверку:

# Система и ресурсы
uname -a
free -h
df -h
swapon --show

# Сеть и firewall
ss -tulpn
ufw status verbose

# Сервисы
systemctl --failed
# Выполняйте следующие команды в каталоге compose-проекта, если он используется:
docker compose ps
docker compose logs --tail=100

# Публичный ответ
curl -I https://example.ru

Команда ss показывает локальные слушающие порты. Доступность снаружи проверяйте также из внешней сети.

Ожидаемый результат:

• вход по SSH работает только по ключу для рабочего пользователя;
• root-вход и парольная авторизация отключены;
• активен jail sshd в fail2ban;
• снаружи доступны только запланированные порты;
• HTTPS отвечает без ошибки сертификата;
• контейнеры или systemd-сервисы переживают перезагрузку;
• внешний мониторинг видит сервис;
• тестовое восстановление дампа или резервной копии выполнено.

Эталонный чеклист развёртывания

Следующий шаг

Yandex Cloud: карта сервисов под ИИ-проект

Связанные материалы

• Статья: Как я провёл аудит серверов Timeweb с Codex
• Блог: EmDash — Cloudflare собрал «наследника WordPress» за два месяца с помощью ИИ-агентов
• База знаний: Cloudflare DNS, Workers и Tunnels — три сервиса, которые должен знать каждый разработчик

Если вы выбираете архитектуру для сайта, API или внутреннего ИИ-контура, полезно заранее сверить требования к данным, сети, резервированию и эксплуатации.

Если захотите обсудить, как это применить у себя или в команде — пишите в Telegram @pimenov