Несколько серверов на одном аккаунте — управление и биллинг

MAATRIX GAMES

Держишь один Minecraft-сервер для своих, потом друзья просят Rust, кто-то из комьюнити хочет CS2 для турнира — и вот вместо одного заказа у вас уже три, каждый со своим логином, своим счётом и своим паролем от панели, которые вечно путаются. На деле всё это можно свести в одно место: один аккаунт MAATRIX GAMES спокойно держит сколько угодно серверов, и биллинг по ним не обязан превращаться в отдельную бухгалтерию. Разберём, как это устроено на практике — от структуры кабинета до того, что происходит со счётом, если один из проектов просрочен, а остальные в порядке.

Один аккаунт — много серверов: как это устроено

В личном кабинете MAATRIX GAMES сервер — это отдельная сущность, привязанная к аккаунту, а не аккаунт, привязанный к серверу. Заказывая второй, третий, десятый сервер, вы не создаёте новую учётку — просто оформляете новый заказ из того же кабинета, и он добавляется в общий список. У каждого сервера свой ID, свой IP:порт, свои файлы и своя консоль, но логин и пароль от кабинета остаются одни на всё.

Список серверов открывается сразу после входа — карточками или таблицей (переключается в настройках отображения), где по каждому видно: название, игру, статус (running/stopped), тариф и локацию (UK/US/RU). Клик по карточке разворачивает панель управления именно этим сервером — файловый менеджер, консоль, бэкапы, настройки — всё изолировано от соседних проектов. Зайти в файлы Rust-сервера и случайно задеть конфиг Minecraft-сервера технически невозможно: это разные контейнеры на инфраструктуре, объединяет их только запись в вашем аккаунте.

Практический плюс такой структуры — единый вход. Не нужно держать в менеджере паролей три-четыре разных логина для разных проектов, не нужно каждый раз выходить и заходить под другим аккаунтом, чтобы перезапустить сервер друга. Актуально для тех, кто администрирует сеть серверов для сообщества или ведёт небольшой хостинг-бизнес на перепродаже (об этом разница с одним универсальным сервером против нескольких нишевых разобрана отдельно) — один универсальный сервер или несколько нишевых.

Именование и организация серверов

Когда серверов больше двух, первая проблема — не спутать их между собой. По умолчанию новый сервер получает техническое имя вида srv-XXXXX, и если не переименовать, через месяц-другой вы будете гадать, какой из трёх srv-48213, srv-51092 и srv-53401 — это тестовый Rust, а какой — боевой ARK для клана.

Переименование делается в настройках сервера (вкладка General → Server Name), имя произвольное, до 64 символов, поддерживает кириллицу. Практика, которая реально экономит время: включать в имя игру, назначение и локацию сразу — например MC-Vanilla-Friends-UK или Rust-Vanilla-2x-US. Это не техническое поле для парсинга, чисто человекочитаемое — но именно оно отображается в списке серверов, в письмах биллинга и в уведомлениях, так что от него реально зависит, насколько быстро вы поймёте, о каком сервере идёт речь в 2 часа ночи, когда пришло алерт-письмо о падении.

Дополнительно можно группировать серверы тегами (если у вас доступна эта функция в кабинете) — например по проекту или по клиенту, если вы администрируете серверы не только для себя. Фильтр по тегу в списке серверов резко сокращает время поиска, когда счёт идёт на десяток+ серверов.

Тарифы: отдельный на каждый сервер

Ключевой момент, который путает новичков: тариф выбирается индивидуально для каждого сервера, а не один на весь аккаунт. Это логично — Minecraft-сборка с десятком модов и Rust на 2x-рейтах нагружают железо совершенно по-разному, и если бы тариф был общим на аккаунт, пришлось бы либо переплачивать за самый прожорливый проект на всех, либо всем не хватало бы ресурсов.

На практике это выглядит так: в кабинете можно держать одновременно Rust-сервер на тарифе Гейм (для нагруженного 2x-рейт проекта на 40+ игроков), Minecraft на Базовом (небольшая ванильная сборка для друзей) и CS2 на Старте (площадка для тренировок на пятерых). Каждый апгрейдится и понижается независимо — апгрейд одного проекта никак не трогает остальные, подробнее о механике перехода на больший тариф без потери мира — апгрейд тарифа без потери мира и сохранений.

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

Биллинг: общий счёт или раздельная оплата

Здесь у MAATRIX GAMES гибкость в обе стороны. По умолчанию биллинг общий: в разделе «Баланс» аккаунта лежит единый счёт, с которого автоматически списывается оплата за все активные серверы в даты их продления. Пополнили баланс один раз — система сама разносит списания по каждому серверу согласно его тарифу и циклу оплаты (у серверов может быть разный день продления, если они куплены в разные даты).

Плюс такой схемы — не нужно помнить три-четыре даты платежа и переключаться между способами оплаты под каждый сервер отдельно. Пополнение баланса работает через карту РФ, СБП или криптовалюту — способ один, применяется ко всем проектам сразу, детали по каждому способу разобраны отдельно: оплата картой РФ, оплата через СБП, оплата криптовалютой.

Минус общего баланса — если вы администрируете серверы не только для себя, а, например, часть проектов принадлежит друзьям или клиентам, смешивать их деньги на одном балансе неудобно для учёта: непонятно, чья доплата покрыла чей апгрейд. Для таких случаев в разделе «История платежей» есть детализация по каждому серверу отдельно — списания, продления и апгрейды логируются с привязкой к ID конкретного сервера, так что при желании можно вручную свести расходы по каждому проекту, даже если баланс общий физически.

История платежей и отчётность по каждому серверу

Раздел «История платежей» — это журнал всех транзакций аккаунта: пополнения баланса, автосписания за продление, доплаты за апгрейд тарифа, возвраты. У каждой строки есть привязка к конкретному серверу (по имени и ID), дата, сумма и статус (успешно/отклонено/в обработке). Экспорт истории доступен в CSV — полезно, если ведёте свою табличку расходов по проектам или закрываете бухгалтерию для юрлица (для оплаты от компании есть отдельная процедура с закрывающими документами — оплата игрового хостинга для юрлиц и ИП).

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

Пример строки истории:
2026-08-24 | Rust-Vanilla-2x-US (ID 51092) | Продление тарифа Гейм | -1899 ₽ | Успешно
2026-08-22 | MC-Vanilla-Friends-UK (ID 48213) | Пополнение баланса | +3000 ₽ | Успешно
2026-08-20 | CS2-Practice-RU (ID 53401) | Апгрейд Старт → Базовый | -412 ₽ | Успешно

Что происходит, если один сервер просрочен, а другие в порядке

Просрочка платежа не «замораживает» весь аккаунт — каждый сервер отслеживает свой собственный статус оплаты независимо. Если баланса не хватило на продление именно Rust-сервера, а Minecraft и CS2 оплачены на месяц вперёд, приостанавливается только Rust: он уходит в статус Suspended, но два других продолжают работать как ни в чём не бывало. Общий алгоритм грейс-периода и удаления данных при неуплате не зависит от того, сколько у вас серверов на аккаунте — он одинаковый для каждого отдельно взятого сервера, подробности — просрочка оплаты — что происходит с сервером.

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

Совместный доступ и разграничение прав между серверами

Если сеть серверов администрируете не только вы — например, есть со-админ на Rust-проекте и отдельный модератор на Minecraft, — панель поддерживает выдачу доступа на уровне отдельного сервера, а не всего аккаунта целиком. В настройках конкретного сервера есть вкладка Access / Совместный доступ, где по email приглашается второй пользователь с ограниченными правами: доступ к консоли и файловому менеджеру этого сервера, но без доступа к биллингу аккаунта, к остальным серверам и без права их удалить или изменить тариф.

Это разграничение стоит настраивать сразу, если планируете кому-то доверить администрирование одного из проектов на общем аккаунте — иначе придётся либо шарить логин и пароль от всего кабинета (риск для остальных серверов и для баланса), либо заводить со-админу отдельный аккаунт и терять единство биллинга, ради которого всё это затевалось. Двухфакторная аутентификация на сам аккаунт при этом остаётся отдельной рекомендуемой мерой — она защищает вход в кабинет целиком, независимо от того, сколько серверов и совместных доступов внутри — двухфакторная аутентификация для панели управления сервером.

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