Пошаговая настройка VPS под стартапа на старте с нуля

MAATRIX

У основателя на старте нет лишнего времени, а сервер нужен вчера. Пошаговая настройка VPS под стартап на старте с нуля — это понятный маршрут от пустой машины до боевого домена с HTTPS, базой и работающим деплоем за один вечер. Ниже проведём весь путь по шагам: безопасность, веб-сервер, база данных, сертификат и первый выкат кода, без лишней теории и с объяснением, зачем нужен каждый шаг.

С чего начинается сервер стартапа

Прежде чем открывать консоль, определитесь с двумя вещами: локацией и стеком. Локация задаёт пинг и юридику. Если аудитория в России и вы работаете с персональными данными — берите RU-локацию, это и требование 152-ФЗ, и минимальная задержка до пользователей. Если продукт международный или нужен зарубежный IP — смотрите на США или Великобританию. У MAATRIX доступны все три локации, а оплата идёт из России картой, СБП или криптой, что снимает вопрос с зарубежными платежами на старте.

Стек определяет, что именно вы будете ставить. Для большинства ранних продуктов это связка «веб-сервер как обратный прокси плюс приложение на вашем языке плюс база данных». Мы разберём универсальную последовательность на примере Nginx, PostgreSQL и приложения под управлением systemd — она подходит для Node.js, Python, Go и почти любого другого рантайма с минимальными правками. Конфигурации сервера достаточно средней: 2 ядра, 4 ГБ RAM и NVMe-диск закрывают старт с запасом.

Держите под рукой доменное имя — оно понадобится для сертификата. Если домена ещё нет, зарегистрируйте его заранее и направьте A-запись на IP сервера: DNS обновляется не мгновенно, и лучше, чтобы к моменту выпуска TLS запись уже разошлась.

Шаг 1. Подключение, обновление, пользователь

Подключитесь к серверу по SSH и первым делом обновите систему — это закрывает известные уязвимости:

ssh root@ВАШ_IP
apt update && apt upgrade -y

Работать постоянно под root — плохая привычка: одна ошибочная команда может стоить сервера. Заведите отдельного пользователя с правами sudo и дальше живите под ним. Скопируйте на сервер свой SSH-ключ, проверьте вход по ключу и только затем отключите парольный вход.

adduser deploy
usermod -aG sudo deploy

Этот шаг занимает пару минут, но задаёт правильную гигиену с самого начала. Когда в проекте появятся коллеги, каждому заводится свой пользователь и свой ключ — это и удобнее, и безопаснее, чем общий root-доступ, который невозможно ни отозвать точечно, ни привязать к конкретному человеку в логах.

Шаг 2. Фаервол и защита от перебора

Сервер с публичным IP сканируют боты в первые же минуты. Закройте всё лишнее фаерволом, оставив только SSH и веб-порты:

ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable

Поставьте fail2ban — он автоматически банит адреса, которые подбирают пароли или ломятся на сервисы. В связке с входом только по ключу это закрывает самый частый вектор атаки на молодой сервер. Не откладывайте безопасность «на потом, когда будет что защищать»: как раз на старте, пока вы заняты продуктом и не следите за логами, сервер наиболее уязвим. Правильно настроенный периметр работает молча и не требует внимания месяцами, тогда как последствия взлома на раннем этапе способны похоронить проект вместе с данными пользователей и репутацией.

Шаг 3. Веб-сервер и обратный прокси

Nginx стоит перед вашим приложением: принимает запросы из интернета, раздаёт статику и проксирует динамику на локальный порт приложения. Установка тривиальна:

apt install -y nginx

В конфиге сайта вы описываете server_name с вашим доменом и блок location /, который проксирует запросы на порт приложения (например proxy_pass http://127.0.0.1:3000). Такая схема даёт сразу несколько выгод: приложение не смотрит в интернет напрямую, статику отдаёт быстрый Nginx, а не рантайм, и в будущем перед несколькими инстансами приложения легко поставить балансировку. Проверяйте конфиг перед перезагрузкой командой nginx -t — она ловит опечатки до того, как они уронят сайт.

Шаг 4. База данных и её изоляция

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

apt install -y postgresql
sudo -u postgres createuser --pwprompt app_user
sudo -u postgres createdb -O app_user app_db

Сразу настройте ежедневный бэкап через pg_dump в cron и отправляйте копии за пределы сервера — на объектное хранилище или второй сервер. И обязательно хотя бы раз проверьте восстановление из копии на тестовой базе: бэкап, который никогда не разворачивали, слишком часто оказывается нерабочим именно в момент аварии. Эта простая привычка отличает проект, переживший сбой диска, от проекта, потерявшего всё.

Шаг 5. TLS-сертификат и HTTPS

Сайт без HTTPS в 2026 году несерьёзен: браузеры помечают его как небезопасный, а часть API и платёжек вообще откажется работать. Бесплатный сертификат Let's Encrypt выпускается и продлевается автоматически:

apt install -y certbot python3-certbot-nginx
certbot --nginx -d ваш-домен.ru -d www.ваш-домен.ru

Certbot сам пропишет редирект с HTTP на HTTPS и настроит автопродление через таймер systemd — вам больше не придётся об этом думать, сертификат будет обновляться сам за месяц до истечения. Проверьте, что сайт открывается по https:// с валидным замком, и на этом публичная часть готова принимать трафик безопасно.

Шаг 6. Запуск приложения и деплой

Приложение должно переживать перезагрузку сервера и падения — для этого его запускают под менеджером процессов. Простейший надёжный вариант — unit systemd, который поднимает ваш процесс, перезапускает при сбое и стартует при загрузке сервера. Опишите в unit рабочую директорию, команду запуска и пользователя, затем включите автозапуск через systemctl enable --now ваше-приложение.

Деплой на старте держите простым: git pull, установка зависимостей, миграции базы, перезапуск сервиса. Оформите это в короткий скрипт, чтобы выкат был одной командой и вы не забывали шаги в спешке. Полноценный CI/CD с автотестами и автоматическим выкатом добавите позже, когда команда вырастет, — на раннем этапе он чаще отнимает время, чем экономит. Когда продукт наберёт нагрузку и одному серверу станет тесно, вертикальный апгрейд или второй сервер у MAATRIX подключаются из панели за минуты с привычной оплатой из России, так что расти вы будете без болезненных переездов и простоев.

Частые вопросы