Как установить и настроить MongoDB на VPS

MAATRIX

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

Сколько ресурсов нужно MongoDB

MongoDB любит оперативную память: движок WiredTiger держит в кэше «горячие» данные и индексы, и чем больше их помещается в RAM, тем быстрее работают запросы. Для небольшого проекта хватает 2 ГБ, для рабочего приложения с активными данными берите 4 ГБ и выше. Особенно важно, чтобы в память помещались индексы — если они не влезают, MongoDB начинает читать их с диска, и производительность резко падает.

Диск тоже имеет значение: документы с индексами занимают место, а WiredTiger хоть и сжимает данные, но под активную запись нужен запас по SSD и по скорости диска. Локацию выбирайте по аудитории: для российского приложения — RU-сервер с минимальным пингом и хранением персональных данных в стране по 152-ФЗ, для зарубежного сервиса — US или UK.

Примеры даны для Ubuntu 24.04 LTS, работаем под пользователем с sudo. MongoDB обычно живёт рядом с бэкендом, и держать их в одной сети правильно — так задержка между приложением и базой минимальна.

Установка из официального репозитория

В репозитории Ubuntu MongoDB нет (её убрали из-за смены лицензии), поэтому ставим из официального репозитория MongoDB — это к тому же даёт свежую версию:

curl -fsSL https://www.mongodb.org/static/pgp/server-8.0.asc | \
  sudo gpg -o /usr/share/keyrings/mongodb-server-8.0.gpg --dearmor
echo "deb [signed-by=/usr/share/keyrings/mongodb-server-8.0.gpg] \
  https://repo.mongodb.org/apt/ubuntu noble/mongodb-org/8.0 multiverse" | \
  sudo tee /etc/apt/sources.list.d/mongodb-org-8.0.list
sudo apt update
sudo apt install -y mongodb-org
sudo systemctl enable --now mongod

Проверьте, что сервер запустился и отвечает:

sudo systemctl status mongod
mongosh --eval "db.runCommand({ ping: 1 })"

Ответ с ok: 1 означает, что MongoDB работает. Конфиг лежит в /etc/mongod.conf, данные — в /var/lib/mongodb, логи — в /var/log/mongodb. По умолчанию база слушает только localhost и работает без авторизации — и вот это надо немедленно исправить.

Включение авторизации: самый важный шаг

Свежая MongoDB не требует пароля. Пока она слушает только localhost, это терпимо, но перед любым сетевым доступом авторизацию нужно включить обязательно. Сначала создайте административного пользователя, подключившись локально:

mongosh

use admin
db.createUser({
  user: "admin",
  pwd: "слоЖный_Пароль_2026",
  roles: [ { role: "userAdminAnyDatabase", db: "admin" }, "readWriteAnyDatabase" ]
})

Теперь включите режим авторизации в конфиге:

sudo nano /etc/mongod.conf

security:
  authorization: enabled

Перезапустите сервер: sudo systemctl restart mongod. Теперь подключение без логина и пароля не даёт доступа к данным. Заходите так: mongosh -u admin -p --authenticationDatabase admin. Это ключевой барьер безопасности — именно отсутствие авторизации в своё время привело к массовому угону тысяч открытых баз MongoDB по всему интернету.

Важно понимать порядок действий и не запутаться в «проблеме курицы и яйца». Пока авторизация выключена, вы можете создать первого пользователя локально без пароля — это специальная лазейка localhost exception, которая работает ровно до момента, когда в базе появляется первый пользователь и включается authorization: enabled. После этого войти можно только по учётным данным. Поэтому сначала создаём администратора, и только потом включаем авторизацию и перезапускаем сервер. Если сделать наоборот, вы рискуете заблокировать сами себя, и придётся временно отключать авторизацию, чтобы создать пользователя. Запомните эту последовательность — она экономит нервы.

Пользователь под приложение

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

use appdb
db.createUser({
  user: "appuser",
  pwd: "другой_Пароль_2026",
  roles: [ { role: "readWrite", db: "appdb" } ]
})

Роль readWrite даёт приложению читать и писать в своей базе, но не трогать чужие данные и настройки сервера. Это принцип минимальных прав: даже при утечке пароля приложения злоумышленник ограничен одной базой. Для сервисов, которым нужно только читать (аналитика, отчёты), заводите пользователя с ролью read. Правило простое: одно приложение — один пользователь со своими правами на свою базу.

MongoDB не требует заранее описывать схему и создавать базу или коллекцию отдельной командой — они появляются автоматически при первой вставке документа. Это удобно на старте, но у гибкости есть обратная сторона: без дисциплины в коллекции легко накапливаются документы с разной структурой, и потом сложно строить запросы. Договоритесь о структуре документов на уровне приложения и по возможности используйте валидацию схемы ($jsonSchema) на важных коллекциях — так вы сохраните гибкость там, где она нужна, и порядок там, где он важен. Индексы тоже стоит закладывать сразу: на поля, по которым чаще всего идёт поиск, повесьте индексы с самого начала, не дожидаясь, пока коллекция вырастет и запросы начнут тормозить.

Сетевой доступ и фаервол

По умолчанию MongoDB привязана к localhost. Если база и приложение на одном сервере, оставьте так — это безопаснее всего. Для доступа с другого сервера добавьте внутренний адрес в конфиг:

net:
  port: 27017
  bindIp: 127.0.0.1,10.0.0.5

Обязательно закройте порт 27017 фаерволом для всех, кроме доверенных адресов:

sudo ufw allow from 10.0.0.20 to any port 27017 proto tcp

Категорически нельзя ставить bindIp: 0.0.0.0 с доступом из интернета — это та самая ошибка, из-за которой угоняли базы. Даже с включённой авторизацией открытый в мир порт MongoDB постоянно сканируется и атакуется. Идеальный вариант — приватная сеть или SSH-туннель между серверами, тогда порт вообще не смотрит в публичный интернет. Комбинация «авторизация плюс привязка к приватному адресу плюс фаервол» закрывает практически все реальные угрозы.

Тюнинг кэша и бэкап

Главный параметр производительности — размер кэша WiredTiger. По умолчанию MongoDB отдаёт под него примерно половину RAM минус гигабайт, что разумно, но на сервере, где кроме базы работает что-то ещё, кэш стоит ограничить явно, чтобы MongoDB не конкурировала за память:

storage:
  wiredTiger:
    engineConfig:
      cacheSizeGB: 2

Бэкап настройте сразу. Для небольших и средних баз подходит логический дамп через mongodump:

mongodump --username admin --authenticationDatabase admin --db appdb --out /var/backups/mongo_$(date +%F)

Восстановление делается симметрично через mongorestore. Автоматизируйте задачу через cron ежедневно и держите копию вне сервера. Чтобы MongoDB работала быстро и стабильно, нужен VPS с достаточной памятью и SSD. В MAATRIX можно арендовать сервер под MongoDB в России, США или Великобритании и оплатить картой РФ, по СБП, криптой или токеном MAAT — иностранная карта не нужна.

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