MinIO на VPS: власне S3-сховище на Ubuntu 24.04

Що дає self-hosted object storage на базі MinIO

MinIO — це self-hosted object storage із підтримкою Amazon S3 API. Вкажіть адресу власного сервера в restic або будь-якому S3 SDK, змініть лише параметр endpoint — і клієнт не помітить різниці. У цьому посібнику розглянуто налаштування одного вузла на Ubuntu 24.04: перевірений бінарний файл, окремий системний користувач, unit systemd, який не зберігає root credentials у своєму файлі, і bucket, у який restic записує резервні копії.

S3 (simple storage service) — це HTTP API, а не файлова система. Ви виконуєте PUT об’єкта в bucket за певним key, а потім GET цього об’єкта. Часткового запису та перейменування немає. Така модель зручна для засобів резервного копіювання, оскільки об’єкт або записано повністю, або його не записано.

Один вузол зберігає одну копію даних. Саме на це ви погоджуєтеся. Ви отримуєте контрольований S3 endpoint за ціною VPS, але також перебираєте на себе всі завдання, які раніше виконував cloud provider: від заміни несправного диска до встановлення оновлень серверного програмного забезпечення. У розділі ближче до кінця прямо пояснено, коли такий компроміс виправданий.

Стан community edition MinIO у липні 2026 року

Прочитайте цей розділ перед розгортанням, оскільки нещодавно ситуація змінилася. У травні 2025 року MinIO вилучив функції адміністрування з вебконсолі community edition. У браузері залишився переглядач об’єктів, тому бакети та ключі доступу тепер керуються за допомогою клієнта командного рядка mc.

Пізніше, у 2025 році, MinIO припинив публікувати попередньо скомпільовані бінарні файли community edition. Тепер у README проєкту зазначено, що community edition поширюється лише у вигляді вихідного коду. Старі URL-адреси для завантаження досі працюють: станом на липень 2026 року вони надають server build RELEASE.2025-09-07T16-13-09Z і client build RELEASE.2025-08-13T08-35-41Z, а новіших community build не з’явилося. Тому наведений нижче бінарний файл є справжнім і працює, але його версію зафіксовано. Виправлення безпеки, опубліковані після вересня 2025 року, у ньому відсутні.

Цей факт визначає подальші кроки в цьому посібнику. Саме тому MinIO тут прослуховує 127.0.0.1, а доступ до інтернету отримує лише через проксі, який ви контролюєте. Якщо потрібно стежити за виправленнями, зберіть MinIO з вихідного коду. У README постачальника наведено одну команду — go install github.com/minio/minio@latest. Для неї потрібен Go toolchain, а бінарний файл записується до ~/go/bin/minio. Установіть цей бінарний файл у /usr/local/bin/minio, і всі інші кроки залишаться без змін.

Установіть бінарний файл MinIO та перевірте завантаження

Завантажте зафіксований реліз і опубліковану контрольну суму для нього. Прапорець -f змушує curl завершувати роботу з помилкою HTTP, а не зберігати сторінку помилки під запитаним іменем. Інакше можна встановити сторінку 404, а потім з’ясовувати, чому вона не запускається.

cd /tmp
REL=RELEASE.2025-09-07T16-13-09Z
curl -fsSL "https://dl.min.io/server/minio/release/linux-amd64/archive/minio.$REL" -o minio
curl -fsSL "https://dl.min.io/server/minio/release/linux-amd64/archive/minio.$REL.sha256sum" -o minio.sha256sum

Порівняйте два хеші. Порівнюйте лише хеші.

published=$(awk '{print $1}' minio.sha256sum)
downloaded=$(sha256sum minio | awk '{print $1}')
[ "$published" = "$downloaded" ] && echo "checksum ok"

Не використовуйте тут sha256sum -c minio.sha256sum. Мітка, записана після хешу у цьому файлі, — minio.RELEASE.2025-09-07T16-13-09Z, а завантаження ми зберегли як minio, тому -c шукає файл, якого не існує. Команда виводить No such file or directory, а потім WARNING: 1 listed file could not be read. Це схоже на пошкоджене завантаження, але ним не є. Мітка — лише ім’я. Гарантію забезпечує саме хеш.

Чітко розумійте, що доводить ця перевірка. Бінарний файл і хеш походять від одного постачальника та передані через одне й те саме з’єднання, тому збіг доводить, що завантаження завершене і дані не було пошкоджено або змінено під час передавання. Це не доводить, що постачальнику можна довіряти. Це окрема проблема, і жодна команда sha256sum її не вирішує.

sudo install -o root -g root -m 755 minio /usr/local/bin/minio
minio --version

minio --version виводить minio version RELEASE.2025-09-07T16-13-09Z, а потім кілька рядків про збірку. Permission denied у цьому випадку означає неправильний режим, а command not found — що /usr/local/bin немає у вашому PATH.

Створіть системного користувача та каталог даних

MinIO приймає завантаження з мережі, тому його не слід запускати від імені root. Створіть для нього обліковий запис без домашнього каталогу та оболонки входу.

sudo groupadd -r minio-user
sudo useradd -M -r -g minio-user -s /usr/sbin/nologin minio-user
sudo mkdir -p /var/lib/minio/data
sudo chown -R minio-user:minio-user /var/lib/minio
sudo chmod 750 /var/lib/minio

-r створює системний обліковий запис із UID менше ніж 1000, тому він не потрапляє в діапазон, призначений для користувачів. -M пропускає створення домашнього каталогу, оскільки обліковому запису, який ніколи не виконує вхід, нічого там зберігати. Перевірте результат за допомогою id minio-user і stat -c '%U %a' /var/lib/minio, яка має вивести minio-user 750.

Каталог даних має бути доступним для запису цьому користувачеві, а не лише для читання. Під час першого запуску MinIO створює каталог .minio.sys усередині тому для зберігання власної конфігурації, тому каталог, власником якого є root, спричиняє завершення MinIO під час запуску з повідомленням, що закінчується на permission denied. Це саме правило застосовується до кожного сервісу, який ви запускаєте таким способом, а в матеріалі про користувачів сервісів із мінімальними привілеями на VPS це належно розглянуто.

Розмістіть облікові дані root у файлі середовища

Облікові дані root відкривають доступ до кожного bucket, тому їм не місце у файлі unit, доступному для читання всіма користувачами. Спочатку створіть файл із правильним режимом доступу, а потім запишіть у нього дані. Так пароль не перебуватиме у доступному для читання файлі навіть короткий час.

sudo install -o root -g root -m 600 /dev/null /etc/default/minio
printf 'MINIO_ROOT_USER=minio-root\nMINIO_ROOT_PASSWORD=%s\nMINIO_VOLUMES="/var/lib/minio/data"\nMINIO_OPTS="--address 127.0.0.1:9000 --console-address 127.0.0.1:9001"\n' "$(openssl rand -base64 24)" | sudo tee /etc/default/minio > /dev/null
sudo sed -n 's/^MINIO_ROOT_PASSWORD=//p' /etc/default/minio

tee очищує наявний файл, а не створює його заново, тому режим доступу залишається 600, а власником — root. Це зроблено навмисно. systemd читає EnvironmentFile від імені root, перш ніж знизити привілеї до User=. Тому обліковому запису сервісу не потрібно читати власні облікові дані. Після запуску сервісу перевірте це за допомогою sudo -u minio-user cat /etc/default/minio. Команда має вивести Permission denied.

Перед запуском MinIO варто знати про дві його особливості. Якщо в середовищі немає MINIO_ROOT_USER і MINIO_ROOT_PASSWORD, MinIO не відмовляється запускатися. Він запускається з документованими обліковими даними за замовчуванням minioadmin:minioadmin. Це перша пара, яку перевіряє будь-який сканер, і під час цього MinIO виглядає повністю справним. Пароль довжиною менше 8 символів відхиляється інакше: MinIO завершує роботу під час запуску з помилкою про недійсні облікові дані, оскільки ключ доступу має містити щонайменше 3 символи, а секретний ключ — щонайменше 8.

MINIO_VOLUMES — це шлях до даних, а MINIO_OPTS містить прапорці. Прив’язка до 127.0.0.1 означає, що з-поза меж цього VPS наразі ніхто не може звернутися до S3 API. Це правильне значення за замовчуванням. Пізніше ви навмисно відкриєте доступ через проксі, на якому встановлено сертифікат.

Створіть unit systemd

Створіть /etc/systemd/system/minio.service:

[Unit]
Description=MinIO object storage
Documentation=https://github.com/minio/minio
Wants=network-online.target
After=network-online.target

[Service]
User=minio-user
Group=minio-user
EnvironmentFile=/etc/default/minio
ExecStart=/usr/local/bin/minio server $MINIO_VOLUMES $MINIO_OPTS
Restart=always
RestartSec=5
LimitNOFILE=65536
NoNewPrivileges=true

[Install]
WantedBy=multi-user.target

На початку EnvironmentFile немає -, і це свідоме рішення, а не помилка. Дефіс указує systemd ігнорувати відсутній файл і все одно запускати MinIO. Тому видалений файл або помилковий шлях непомітно залишає сервер, що працює з minioadmin:minioadmin. Без дефіса відсутній файл зупиняє unit до запуску MinIO, а journalctl -u minio показує Failed to load environment files: No such file or directory. Unit, який відмовляється запускатися, набагато легше помітити, ніж сервер, що непомітно приймає пароль за замовчуванням.

$MINIO_VOLUMES і $MINIO_OPTS навмисно не взято в лапки, оскільки systemd розділяє змінні без лапок за пробілами на окремі аргументи. Саме так чотири слова в MINIO_OPTS перетворюються на чотири аргументи для minio server. LimitNOFILE=65536 збільшує ліміт файлових дескрипторів, оскільки кожне відкрите з’єднання та кожен відкритий файл даних потребують одного дескриптора, а стандартного значення 1024 за навантаження недостатньо.

sudo systemctl daemon-reload
sudo systemctl enable --now minio
systemctl is-active minio
curl -fsS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:9000/minio/health/live

is-active має вивести active, а health endpoint має повернути 200. journalctl -u minio -n 20 --no-pager показує адресу API, на якій сервер приймає з’єднання. Якщо unit постійно перезапускається, systemd припиняє спроби та записує Start request repeated too quickly. Це означає, що MinIO завершує роботу під час кожної спроби. Причину наведено в рядках перед цим повідомленням, тому перегляньте журнал вище.

Для додаткової ізоляції додайте ProtectSystem=full і ProtectHome=true до секції [Service]. Для обох параметрів потрібні mount namespaces від ядра хоста. У контейнерній віртуалізації зі спільним ядром хоста, наприклад OpenVZ або LXC, вони можуть не працювати. Тоді unit повідомляє status=226/NAMESPACE. Видаліть ці два рядки, і unit запуститься. Сам unit є звичайним, а в матеріалі systemd-сервіси й таймери на VPS описано решту директив.

Встановіть mc і перевірте повний цикл

Клієнт MinIO — mc. Не встановлюйте його за допомогою apt install mc. Цей пакет містить Midnight Commander, файловий менеджер, не пов’язаний із MinIO.

cd /tmp
curl -fsSL https://dl.min.io/client/mc/release/linux-amd64/mc -o mc
curl -fsSL https://dl.min.io/client/mc/release/linux-amd64/mc.sha256sum -o mc.sha256sum
[ "$(awk '{print $1}' mc.sha256sum)" = "$(sha256sum mc | awk '{print $1}')" ] && echo "checksum ok"
sudo install -o root -g root -m 755 mc /usr/local/bin/mc

Зареєструйте сервер як alias, а потім перемістіть через нього об’єкт.

MINIO_PASS=$(sudo sed -n 's/^MINIO_ROOT_PASSWORD=//p' /etc/default/minio)
mc alias set local http://127.0.0.1:9000 minio-root "$MINIO_PASS"
mc mb local/backups
echo "hello object storage" > /tmp/hello.txt
mc cp /tmp/hello.txt local/backups/hello.txt
mc ls local/backups
mc cat local/backups/hello.txt

mc ls має вивести hello.txt із його розміром, а mc cat — надрукувати hello object storage. Це підтверджує, що сервер працює, оскільки клієнт виконує ті самі підписані S3-запити, що й будь-який інший клієнт. mc admin info local виводить стан сервера для додаткової перевірки.

Тепер виконайте ще одну перевірку, поки сервер іще порожній.

mc alias set defaultcheck http://127.0.0.1:9000 minioadmin minioadmin

Ця команда має завершитися помилкою. Якщо вона виконується успішно, файл середовища не було передано процесу, і сервер працює з обліковими даними за замовчуванням. Виправте це до того, як до сервера отримає доступ будь-який інший компонент.

mc зберігає alias у ~/.mc/config.json у відкритому тексті, тому ці облікові дані опиняються в домашньому каталозі користувача, який виконав команду. Виконання mc від імені sudo зберігає облікові дані root у /root/.mc/config.json. Залиште root alias в обліковому записі одного адміністратора, а для кожного застосунку створіть власний ключ.

Надання одного об’єкта за presigned URL

Presigned URL — це звичайне HTTPS-посилання, до якого додано підпис і строк дії. Будь-хто, хто має це посилання, може завантажити цей об’єкт без облікового запису та клієнтського застосунку.

mc share download --expire 12h local/backups/hello.txt

У вихідних даних у рядку запиту містяться X-Amz-Signature і X-Amz-Expires. Є два моменти, які часто дивують користувачів. Посилання формується з endpoint, указаного у використаному alias, тому alias на 127.0.0.1 створює посилання, яке можна відкрити лише на цій машині: створіть другий alias для публічного hostname, якщо плануєте надсилати посилання іншим. Кнопки відкликання немає. Підпис залишається чинним до завершення строку дії, тому короткий строк дії — єдиний доступний засіб контролю. Сім днів — максимальний строк, дозволений форматом підпису S3.

Надайте restic окремий ключ і bucket

Облікові дані root дають змогу читати й видаляти всі bucket, тому завдання резервного копіювання не повинно їх використовувати. Створіть bucket, політику з обмеженням для цього bucket і користувача без будь-яких інших дозволів.

mc mb local/restic
cat > /tmp/restic-rw.json <<'EOF'
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:ListBucket", "s3:GetBucketLocation"],
      "Resource": ["arn:aws:s3:::restic"]
    },
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject", "s3:DeleteObject"],
      "Resource": ["arn:aws:s3:::restic/*"]
    }
  ]
}
EOF
RESTIC_KEY=$(openssl rand -base64 24)
mc admin policy create local restic-rw /tmp/restic-rw.json
mc admin user add local restic-backup "$RESTIC_KEY"
mc admin policy attach local restic-rw --user restic-backup

MinIO має вбудовану політику readwrite, яка скоротила б цю процедуру на одну команду, але надає повний доступ до кожного bucket на сервері. У наведеній вище політиці bucket навмисно вказано двічі: один раз як arn:aws:s3:::restic, щоб працювало перелічення bucket, і один раз як arn:aws:s3:::restic/* для об’єктів у ньому. У S3 bucket і його об’єкти є окремими ресурсами, тому політика, у якій указано лише один із них, завершується помилкою, що виглядає як несправність клієнта.

Перевірте обмеження, перш ніж покладатися на нього.

mc alias set resticuser http://127.0.0.1:9000 restic-backup "$RESTIC_KEY"
mc ls resticuser/restic
mc ls resticuser/backups

Перша команда ls виконується успішно, а друга завершується помилкою Access Denied. Неперевірена політика — це лише припущення.

Тепер налаштуйте restic для роботи з bucket. restic читає облікові дані S3 зі стандартних змінних середовища AWS, тому окремий файл облікових даних для restic не потрібен.

sudo apt install -y restic
export AWS_ACCESS_KEY_ID=restic-backup
export AWS_SECRET_ACCESS_KEY="$RESTIC_KEY"
restic -r s3:http://127.0.0.1:9000/restic init
restic -r s3:http://127.0.0.1:9000/restic backup /etc
restic -r s3:http://127.0.0.1:9000/restic snapshots

restic init запитує пароль репозиторію. Цей пароль шифрує репозиторій, тому MinIO зберігає лише шифротекст, а втрата пароля означає втрату резервної копії. Завдання, запущене таймером systemd, не має термінала для введення пароля, тому для запланованих резервних копій збережіть RESTIC_PASSWORD_FILE у файлі з правами доступу 600.

Єдине правило розміщення важливіше за будь-яку наведену вище команду. Репозиторій restic на тому самому VPS, що й дані, які він захищає, уберігає лише від невдалого rm. Від інших проблем він не захищає. Вузол MinIO має бути на іншій машині, бажано в іншому регіоні. Резервні копії restic на VPS описує налаштування розкладу та зберігання резервних копій поверх цієї схеми.

Завершення TLS через nginx

MinIO працює на localhost, тому nginx є публічною точкою доступу. Спочатку отримайте сертифікат, як описано в розділі Сертифікати Let's Encrypt за допомогою certbot і nginx, а потім використайте цей server block.

server {
    listen 443 ssl;
    server_name s3.example.com;

    ignore_invalid_headers off;
    client_max_body_size 0;
    proxy_buffering off;
    proxy_request_buffering off;

    location / {
        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_connect_timeout 300;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        chunked_transfer_encoding off;
        proxy_pass http://127.0.0.1:9000;
    }
}

Деякі з цих рядків критично важливі. client_max_body_size 0 вимикає стандартне обмеження розміру тіла запиту 1 MB. Інакше nginx відхилить будь-яке більше завантаження з помилкою 413 Request Entity Too Large, ще до того як запит надійде до MinIO. proxy_request_buffering off передає завантаження безпосередньо далі, оскільки за замовчуванням весь запит спочатку записується в тимчасовий файл. Тому для великого об’єкта потрібно вдвічі більше дискового простору. proxy_set_header Host $http_host є менш очевидним параметром: підпис S3 охоплює заголовок Host, тому проксі, який змінює його, спричиняє помилку SignatureDoesNotMatch для кожного запиту, хоча в журналі доступу видно, що звичайний запит надійшов.

Також повідомте MinIO його публічне ім’я, щоб згенеровані ним посилання вказували на проксі, а не на localhost.

echo 'MINIO_SERVER_URL=https://s3.example.com' | sudo tee -a /etc/default/minio
sudo systemctl restart minio

Правила firewall залишаються мінімальними. Дозвольте SSH і HTTPS, а для портів 9000 і 9001 не створюйте жодного правила. Адреса, прив’язана до 127.0.0.1, недоступна з іншої машини незалежно від налаштувань firewall. У розділі Основи ufw firewall на VPS наведено потрібні команди.

Коли достатньо MinIO на одному вузлі, а коли потрібне справжнє S3

Один вузол у цьому випадку означає один диск без надлишковості. Власна документація MinIO описує таку конфігурацію як придатну для тестування та невеликих навантажень, де доступність не є вимогою. У розгортанні немає другої копії даних, тому довговічність кожного об’єкта визначається довговічністю диска одного VPS. Функції, які передбачають розподілений erasure-coded бекенд, зокрема реплікацію бакетів і блокування об’єктів, належать до розгортань із кількома дисками. Тому не обіцяйте для цієї конфігурації незмінну політику зберігання.

Це хороший варіант як ціль для restic на другому VPS в іншому регіоні, а також як S3 endpoint для розробки й артефактів CI, коли втрата бакета означає лише повторну збірку. Такий варіант також підходить для завантажень користувачів у невеликому застосунку, якщо ви відповідаєте за план відновлення і справді перевірили відновлення на практиці.

Обирайте керований S3, якщо контракт або регулятор вимагає блокування об’єктів чи довговічності в кількох регіонах, або якщо ви не хочете о 03:00 отримати сповіщення про заповнений диск. Інша чесна причина — зафіксована збірка. Станом на July 2026 попередньо скомпільований community binary датований September 2025 і не отримує виправлень. Його запуск означає прийняття цього обмеження або самостійну збірку з вихідного коду та супровід відповідно до змін у проєкті.

Є важливе обмеження, про яке часто запитують. Object storage — не база даних. Кожен запис замінює весь об’єкт, тому робота з актуальним SQL-файлом у S3 bucket повільна й небезпечна. Зберігайте базу даних на локальному диску, а резервні копії створюйте в bucket: запуск SQLite у production на VPS описує такий поділ.

Причини помилок і повідомлення, які ви побачите

Модуль не запускається одразу після systemctl enable --now. Перегляньте journalctl -u minio -n 30 --no-pager. Failed to load environment files: No such file or directory означає, що /etc/default/minio відсутній або його шлях у unit указано неправильно. Повідомлення, яке закінчується на permission denied, означає, що обліковий запис сервісу не має права запису до каталогу даних. Перевірте, чи виводить stat -c '%U' /var/lib/minio/data значення minio-user.

minioadmin:minioadmin і далі виконує вхід. Файл середовища не передався процесу. Переконайтеся, що unit містить EnvironmentFile=/etc/default/minio, виконайте sudo systemctl daemon-reload, а потім перезапустіть сервіс. MinIO читає root-облікові дані один раз під час запуску, тому зміна цього файлу без перезапуску нічого не змінює.

Address already in use під час запуску. Інший процес уже використовує порт 9000. Знайдіть його за допомогою sudo ss -ltnp | grep :9000, перш ніж змінювати порт MinIO.

Завантаження файлів розміром понад 1 MB через проксі завершується помилкою. nginx повернув 413 Request Entity Too Large, і MinIO не отримав запит. Укажіть client_max_body_size 0 у блоці server.

SignatureDoesNotMatch. Неправильний секретний ключ або компонент між клієнтом і MinIO змінив заголовок Host, який входить до підпису.

RequestTimeTooSkewed. Годинник на клієнті або сервері показує неправильний час. Кожен S3-запит містить часову мітку, і система відхиляє запити за межами 15-хвилинного вікна. Перевірте timedatectl і переконайтеся, що синхронізація часу активна.

Access Denied для бакета, про існування якого ви знаєте. Ключ обмежено іншим бакетом. Виведіть дозволи, які фактично надає політика, за допомогою mc admin policy info local restic-rw і порівняйте назву бакета в рядках resource.

FAQ

Чи достатньо одновузлового MinIO для реальних резервних копій?

Цього достатньо як цільового сховища для restic на окремій машині, відмінній від тієї, на якій зберігаються захищені дані. Але цього недостатньо як єдиної копії. У конфігурації з одним диском немає паритету, тому всередині MinIO не зберігається друга копія. Якщо VPS втратить дані на диску, об’єкти буде втрачено. Зберігайте другу копію в іншому місці та хоча б один раз відновіть дані з обох цілей, щоб перевірити працездатність процесу.

Чому sha256sum -c не проходить перевірку файлу контрольної суми MinIO?

Тому що мітка після хешу в цьому файлі містить назву релізу — minio.RELEASE.2025-09-07T16-13-09Z, тоді як завантажений файл зазвичай називається minio. sha256sum -c шукає файл із назвою, записаною у файлі контрольної суми, не знаходить його та виводить No such file or directory і WARNING: 1 listed file could not be read. Завантаження виконано правильно. Порівняйте рядки хешів безпосередньо та проігноруйте мітку, оскільки вона не має безпекового значення.

Куди зникла вебконсоль адміністрування MinIO?

У травні 2025 року MinIO вилучив функції адміністрування з консолі community edition, залишивши у вебінтерфейсі переглядач об’єктів. Тепер бакети й користувачі керуються за допомогою клієнта mc, використовуючи такі команди, як mc admin user add і mc admin policy attach. У community edition це підтримуваний спосіб, а не обхідне рішення, тому в цьому посібнику всі дії виконуються з командного рядка.

Як підключити restic до MinIO як бекенда S3?

Задайте AWS_ACCESS_KEY_ID і AWS_SECRET_ACCESS_KEY для ключа доступу MinIO та відповідного секрету, а потім використайте рядок репозиторію у форматі s3:https://s3.example.com/restic, де останній елемент шляху — назва бакета. Спочатку створіть бакет за допомогою mc mb, оскільки ключ із правами лише для одного бакета не може створювати бакети. Перед завантаженням restic шифрує всі дані власним паролем репозиторію, тому MinIO зберігає шифротекст і ніколи не бачить ваші файли.

Чи потрібно запускати MinIO за nginx?

TLS (захист транспортного рівня) потрібен щоразу, коли клієнт працює на іншій машині, оскільки облікові дані S3 і дані об’єктів передаються всередині запиту. Найпростіший спосіб реалізувати це — проксі на порту 443 із сертифікатом від certbot. Така схема також виносить поновлення сертифіката за межі MinIO. MinIO може сам завершувати TLS, якщо вказати --certs-dir на каталог із public.crt і private.key, але тоді обліковому запису сервісу потрібен доступ на читання оновленого приватного ключа. Це створює додаткову роботу заради того самого результату.