pimenov.ai

База знаний

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

Как выбрать российский VPS (TimeWeb, Selectel, Beget, Yandex Cloud) и развернуть его с нуля: тарифы, SSH, firewall, SSL, IPv4 и мониторинг.

Опубликовано

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

📌
Для кого: разработчики и технические основатели, которым нужен сервер с российской пропиской — под сайт, бота, API или ИИ-контур. Базовое знакомство с терминалом желательно, но все команды готовы к копированию.

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

Зарубежные облака (Hetzner, DigitalOcean, Cloudflare) удобнее и дешевле, но российский сервер выигрывает в нескольких сценариях:

  • Оплата рублями с карты РФ. Зарубежные провайдеры почти все отказались от российских карт, и оплата превращается в квест.
  • 152-ФЗ и персональные данные. Если вы храните перональные данные россиян, по закону они должны лежать на серверах в РФ.
  • Низкий пинг до российской аудитории. Сайт и API из московского дата-центра отвечают пользователям в России на десятки миллисекунд быстрее.
  • Доступность для российских сервисов. Многие API (банки, Госуслуги, Яндекс 360) пускают только российские IP.
💡
Совет: не складывайте всё в одно место. Статику и фронтенд можно отдать на зарубежный CDN, а в российском VPS держать backend, базу и интеграции с локальными сервисами.

TimeWeb, Selectel, Beget и Yandex Cloud: кого выбрать

Четыре провайдера закрывают почти все запросы. Различаются они не ценой, а тем, сколько контроля и сложности вы готовы взять на себя.

ПровайдерКому подходитСильные стороныНа что смотреть
Timeweb CloudБольшинство pet-проектов, сайтов, ботов, MVPЛучшая цена в РФ, простая панель, почасовая оплата, NVMe, дата-центры в РФ и ЕвропеIPv4 оплачивается отдельно; короткий тестовый период
SelectelЗрелые продакшен-проекты, командыГибкая конфигурация, приватные сети, выделенные серверы, сильная репутацияДороже и сложнее на старте
BegetНовички, простые сайты и ботыСамая дружелюбная панель, отличный аптайм, простой биллингМеньше гибкости в конфигурациях
Yandex CloudСерьёзные нагрузки, интеграция с экосистемой Яндекса40+ управляемых сервисов, managed-базы, автоскейлинг, 60 дней триалаВысокий порог входа, выше цена, оплата по факту потребления
⚖️
Trade-off: Timeweb и Beget дают вам «сервер целиком» по фиксированной цене и заставляют настраивать всё руками. Yandex Cloud берёт настройку на себя, но считает деньги за каждый сервис отдельно, и счёт легко вырастает.

Для типичного российского пользователя — личный сайт, Telegram-бот, небольшой API или ИИ-агент — оптимальная отправная точка это Timeweb Cloud: дёшево, понятно и достаточно мощно.


Как выбрать тариф: CPU, RAM, SSD, локация

У Timeweb десятки тарифов, но логика выбора простая.

ПараметрМинимумКомфортЗачем
CPU1 vCPU2 vCPUСборки, Node.js, базы данных любят второе ядро
RAM2 ГБ4 ГБНа 1 ГБ современный стек упирается в нехватку памяти и OOM-killer
Диск30 ГБ NVMe40–80 ГБ NVMeОС, Docker-образы и логи съедают место быстрее, чем кажется
ЛокацияМосква / СПбМосква / СПбМинимальный пинг до российской аудитории

Ориентировочные цены Timeweb на 2026 год: тариф с 2 vCPU / 2 ГБ / 40 ГБ NVMe стоит примерно 700–900 ₽/мес, конфигурация 4 ГБ RAM — около 1 500 ₽/мес. Трафик безлимитный, оплата почасовая, минимальный платёж для старта 50 ₽.

⚠️
Внимание: публичный IPv4-адрес у Timeweb оплачивается отдельно — около 180–200 ₽/мес. Это не «доплата ни за что», а обязательный пункт для большинства задач (см. раздел про IPv4 ниже). Закладывайте его в бюджет сразу.
💡
Совет: берите тип сервера с процессорами 3.3 ГГц (линейка на AMD EPYC) для обычных задач, либо HighCPU 5 ГГц, если важна скорость одного потока (например, синхронные сборки). Почасовая оплата позволяет завести мощный сервер на час для теста и удалить его.

Первичная настройка сервера: Ubuntu, SSH, firewall, fail2ban

Берите Ubuntu 24.04 LTS — это стандарт, под который написана вся документация. Сразу после создания сервера выполните базовую защиту: новый сервер с открытым SSH и паролем root начинают перебирать боты в первые же минуты.

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

apt update && apt upgrade -y

# Создаём пользователя с правами sudo
adduser deploy
usermod -aG sudo deploy

# Переносим свой публичный SSH-ключ новому пользователю
rsync --archive --chown=deploy:deploy ~/.ssh /home/deploy

2. Закройте вход по паролю и под root. Отредактируйте /etc/ssh/sshd_config:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

Применится после systemctl restart ssh. Перед перезапуском проверьте, что ключ работает, в отдельном терминале — иначе можно закрыть себе доступ.

⚠️
Частая ловушка: облачные образы Timeweb и других провайдеров нередко кладут отдельный файл в /etc/ssh/sshd_config.d/, который включает вход по паролю и переопределяет основной конфиг. Если после правок пароль всё ещё принимается, загляните в эту папку и поправьте файлы в ней.

3. Включите firewall. UFW пускает только нужные порты:

ufw default deny incoming
ufw default allow outgoing
ufw allow OpenSSH
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable

4. Поставьте fail2ban. Он банит IP, которые перебирают SSH:

apt install fail2ban -y
systemctl enable --now fail2ban
🔴
Критично: никогда не оставляйте PasswordAuthentication yes вместе с root-доступом на боевом сервере. Это самая частая причина взлома российских VPS.

Гигиена системы: swap, часовой пояс, автообновления

Три небольшие настройки, которые новички пропускают, а потом ловят странные сбои.

Swap-файл. На дешёвых тарифах с 1–2 ГБ RAM сборка фронтенда или запуск базы легко упираются в потолок памяти, и тогда OOM-killer убивает процесс. Swap-файл на 1–2 ГБ даёт системе подушку:

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

Swap медленнее оперативной памяти, поэтому это страховка от падений, а не способ сэкономить на RAM под постоянную нагрузку.

Часовой пояс. По умолчанию сервер живёт в UTC. Если вы смотрите логи и ставите задачи в cron по московскому времени, выставьте пояс сразу, иначе расследование инцидентов превращается в арифметику:

timedatectl set-timezone Europe/Moscow

Автообновления безопасности. Чтобы критические патчи ставились без вашего участия:

apt install unattended-upgrades -y
dpkg-reconfigure --priority=low unattended-upgrades
💡
Совет: автообновления оставьте только для security-патчей. Полное автообновление всех пакетов на боевом сервере иногда ломает рабочие сервисы в самый неудобный момент.

Веб-сервер и SSL: Caddy или nginx

Для нового проекта берите Caddy: он сам получает и продлевает бесплатный сертификат Let's Encrypt, и HTTPS работает из коробки. nginx мощнее и гибче, но требует ручной возни с certbot.

Минимальный Caddyfile для статического сайта с автоматическим HTTPS:

example.ru {
    encode gzip zstd
    root * /var/www/example
    file_server
}

Для приложения, которое слушает локальный порт (Node.js, Python), Caddy работает обратным прокси и так же сам ставит SSL:

api.example.ru {
    reverse_proxy 127.0.0.1:3000
}

Домены. В DNS-записях домена пропишите A-запись на IPv4-адрес сервера. Если домен заведён в Cloudflare, прокси (оранжевое облако) можно оставить включённым — он скроет реальный IP и добавит защиту, но тогда сертификат на сервере и режим SSL в Cloudflare должны совпадать (Full strict).


IPv4 или IPv6: почему адрес IPv4 обязателен

Timeweb даёт IPv6 бесплатно, а IPv4 — за деньги, и возникает соблазн сэкономить и взять сервер только с IPv6. Это ловушка.

⚠️
Внимание: огромная часть внешних сервисов и API до сих пор живёт только в IPv4. Сервер без IPv4-адреса не сможет до них достучаться — исходящие соединения просто не установятся.

Живой пример из практики: конвейер синхронизации Plaud (выгрузка транскриптов через неофициальный API) на IPv6-only сервере молча не работал — эндпоинты сервиса доступны только по IPv4. Диагностика таких проблем коварна: сайт открывается, ping проходит, а конкретная интеграция «без причины» отваливается.

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


Docker: запуск сервисов в контейнерах

Боты, API и базы данных удобно держать в контейнерах: окружение изолировано, а перенос на другой сервер сводится к копированию compose-файла. Установка официального Docker на Ubuntu:

curl -fsSL https://get.docker.com | sh

# Запускать docker без sudo
usermod -aG docker deploy

Дальше сервисы описываются в docker-compose.yml и поднимаются одной командой:

docker compose up -d
⚠️
Внимание: Docker по умолчанию пишет правила прямо в iptables и обходит UFW. Контейнер с ports: 5432:5432 окажется доступен из интернета, даже если этот порт закрыт в UFW. Публикуйте порты только на localhost (127.0.0.1:5432:5432), а наружу отдавайте сервисы через Caddy.

Логи и состояние контейнеров смотрите через docker compose logs -f и docker ps. Долгоживущие стеки запускайте с политикой перезапуска restart: unless-stopped, чтобы они поднимались после перезагрузки сервера.


Деплой Astro и сервисов под Cloudflare Workers

Статический сайт на Astro разворачивается на VPS тривиально: собираете и кладёте результат в директорию, которую отдаёт Caddy.

npm ci
npm run build        # результат в ./dist
rsync -a --delete ./dist/ /var/www/example/

Сложнее с сервисами, написанными под Cloudflare Workers: они рассчитаны на edge-рантайм, а не на обычный Node.js. На своём VPS есть два пути:

  • workerd — официальный опенсорсный рантайм Cloudflare. Запускает Worker-код локально, максимально близко к продакшену Cloudflare.
  • Адаптация под Node.js — если Worker использует только стандартные API, его часто можно собрать под Node-совместимый рантайм (например, через Nitro или Hono с Node-адаптером) и запустить под менеджером процессов.

Любой долгоживущий процесс держите под systemd или pm2, чтобы он переживал перезагрузку сервера и падения.

flowchart LR
    A["Git push"] --> B["Сборка на сервере<br>npm run build"]
    B --> C{"Тип проекта"}
    C -->|"Статика (Astro)"| D["Каталог /var/www"]
    C -->|"Worker / API"| E["workerd или Node + systemd"]
    D --> F["Caddy: HTTPS + домен"]
    E --> F
    F --> G["Пользователь"]

Серверный паспорт и мониторинг

Через полгода вы забудете, что и зачем крутится на сервере. Заведите серверный паспорт — короткий документ (можно прямо в Notion) с ключевой информацией.

📌
Что писать в паспорте сервера: провайдер и тариф, IP-адреса, ОС, список запущенных сервисов и их порты, какие домены ведут на сервер, где лежат бэкапы, дата создания и контакт ответственного.

Минимальный мониторинг, чтобы узнавать о проблемах раньше пользователей:

  • Аптайм-проверка снаружи — бесплатный UptimeRobot или подобный сервис, который пингует сайт и шлёт уведомление при падении.
  • Место на диске — самая частая причина внезапных отказов. Настройте алерт при заполнении выше 80%.
  • Бэкапы — Timeweb предлагает автоматические резервные копии за доплату. Для базы данных дополнительно делайте pg_dump/mysqldump по расписанию в cron.
  • Логиjournalctl -u имя-сервиса и логи Caddy в /var/log подскажут причину при разборе инцидента.
💾
Бэкапы без иллюзий: автоматический бэкап Timeweb копирует диск целиком, но повреждённую базу он сохранит вместе с ошибкой. Держите дампы pg_dump/mysqldump отдельно и складывайте копию вне сервера — другой VPS, объектное хранилище S3 или Synology. И обязательно проверяйте восстановление: бэкап, который ни разу не разворачивали, бесполезен.

Управление всей инфраструктурой через API Timeweb

Панель — не единственный способ управлять серверами. У Timeweb Cloud есть полноценный API, через который можно поднимать и удалять VPS, управлять дисками и снапшотами, читать и менять DNS-записи, настраивать firewall-группы и включать бэкапы. Почти всё, что вы делаете мышкой в панели, доступно программно и воспроизводимо.

Ценность API растёт вместе с числом серверов. Для одной машины хватает панели. Но когда их становится пять или семь, ручная инвентаризация превращается в археологию: вкладка за вкладкой, скриншот за скриншотом. API отдаёт ту же картину одним списком — сколько VPS, какие диски, где включены бэкапы, какие домены и DNS заведены, какие firewall-группы подключены.

💡
Как я это использую: я подключил API Timeweb к ИИ-агенту (Codex) и провёл аудит парка из семи серверов — собрал карту инфраструктуры, нашёл забытые сервисы и закрыл лишние публичные порты, не трогая боевые контуры. Весь процесс описал в статье «Как я провёл аудит серверов Timeweb с Codex».

Два принципа, если выдаёте API-доступ скрипту или агенту:

  • Сначала только чтение. API облака — это кнопка, рядом с которой мелким шрифтом написано «удалить DNS» и «остановить production». Начните с read-only: соберите карту, а изменения вносите отдельными согласованными шагами.
  • Токен — это ключ от всего. Не храните его в коде репозитория и не вставляйте в переписку. Держите в менеджере секретов или переменных окружения и отзывайте, если он мог утечь.

У API есть важное ограничение: он видит облачный слой, но не заглядывает внутрь сервера. Он покажет, что VPS существует, какой у него диск и есть ли бэкап, но не расскажет, что внутри кто-то полгода назад поднял Docker и забыл базу. Полная картина собирается в два слоя — API снаружи и SSH изнутри.


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

Пройдите по списку перед тем, как пускать на сервер боевой трафик:

Создан тариф с IPv4-адресом, локация Москва или СПб
Система обновлена, заведён пользователь с sudo, root-вход по паролю закрыт
SSH работает только по ключу, проверен в отдельном терминале
Включён UFW: открыты только 22, 80, 443
Установлен и запущен fail2ban
Настроены swap-файл, часовой пояс и автообновления безопасности
Сервисы в Docker публикуют порты только на localhost, наружу — через Caddy
Caddy отдаёт сайт по HTTPS, сертификат получен автоматически
A-запись домена указывает на IPv4 сервера
Долгоживущие сервисы под systemd/pm2 и стартуют после перезагрузки
Настроены бэкапы и внешняя аптайм-проверка
Заполнен серверный паспорт
API-токен Timeweb сохранён в безопасном месте (не в коде и не в переписке), если планируете управлять инфраструктурой программно

По теме

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