WordPress на LEMP: пошаговая установка

MAATRIX

Установка WordPress на LEMP отличается от LAMP одной деталью, которая ломает половину инструкций из поиска: у Nginx нет .htaccess. Правила ЧПУ, лимит загрузки и защита wp-config.php переезжают в серверный блок, а PHP исполняет отдельный демон со своими лимитами. Ниже — вся цепочка от apt update до HTTPS: конфиги целиком, замеры и тексты ошибок.

Из чего состоит LEMP и чем вы платите за Nginx

LEMP — это Linux, Nginx, MariaDB (или MySQL) и PHP-FPM. Разница с LAMP в модели памяти: Apache с mod_php держит интерпретатор внутри каждого воркера, 30–60 МБ на соединение, включая запросы за картинками. Nginx отдаёт статику двумя воркерами по 15–25 МБ и зовёт PHP-FPM только за файлами .php. На 2 ГБ это разница между двумя и шестью десятками одновременных посетителей.

Плата — две вещи, о которых лучше знать заранее:

• .htaccess не работает вообще. ЧПУ, правила кеша и редиректы на HTTPS переносятся в конфиг руками, а плагин не ругается: он пишет файл, который никто не читает.
• Лимиты задаются дважды. Размер загрузки — и в PHP, и в client_max_body_size. Забыли второе — медиатека отдаст 413 Request Entity Too Large. Ошибки PHP при этом видны не страницей, а как 502 Bad Gateway в /var/log/nginx/error.log.

Подготовка сервера и версии пакетов

Что вы получите из штатных репозиториев в 2026 году:

Официальный минимум CMS — PHP 7.2.24 и MariaDB 10.4, но плагины 2026 года требуют 8.1 и выше.

apt update && apt -y full-upgrade
apt -y install nginx mariadb-server php-fpm php-mysql php-gd php-curl \
    php-mbstring php-xml php-zip php-intl php-imagick php-opcache
systemctl enable --now nginx mariadb php8.3-fpm
ufw allow 22/tcp && ufw allow 'Nginx Full' && ufw --force enable

Расширения не для красоты: php-gd и php-imagick режут превью, php-curl тянет обновления, php-mbstring и php-intl отвечают за русский текст и даты. Профиль Nginx Full открывает 80 и 443, порт 3306 наружу — никогда. На машине с 2 ГБ сразу добавьте своп и vm.swappiness=10 — чтобы всплеск трафика не пристрелил базу через OOM-killer.

База данных: пользователь, коллация и настройки под 2 ГБ

Закройте свежую установку скриптом mariadb-secure-installation — в MariaDB 11.x это новое имя mysql_secure_installation. Заходите как sudo mariadb: попытка mysql -u root -p из-под обычного пользователя даёт

ERROR 1698 (28000): Access denied for user 'root'@'localhost'

Это не «неверный пароль»: root в MariaDB на Debian и Ubuntu аутентифицируется плагином unix_socket, по системному пользователю, и пароль тут не участвует.

CREATE DATABASE wp_main CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'wp_main'@'localhost' IDENTIFIED BY 'СГЕНЕРИРОВАННЫЙ_ПАРОЛЬ';
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, ALTER, INDEX,
      CREATE TEMPORARY TABLES ON wp_main.* TO 'wp_main'@'localhost';

Пароль — из openssl rand -base64 24. Вместо GRANT ALL — перечисленный набор: WordPress не нужны FILE, PROCESS и SUPER, и это сужает ущерб от инъекции. Коллацию задавайте явно: в новых ветках MariaDB умолчание для utf8mb4 другое, и если залить дамп со старого хостинга в базу, созданную «как получится», на первом же JOIN получите Illegal mix of collations (utf8mb4_uca1400_ai_ci,IMPLICIT) and (utf8mb4_unicode_ci,IMPLICIT) for operation '='.

Тюнинг — в /etc/mysql/mariadb.conf.d/60-wordpress.cnf, чтобы его не затёрло обновление пакета:

[mysqld]
skip-name-resolve
innodb_buffer_pool_size = 384M
innodb_log_file_size = 128M
innodb_flush_method = O_DIRECT
max_connections = 60

Буферный пул — память, где живут таблицы: база блога на 5000 записей весит 150–400 МБ, и держать её в RAM дешевле, чем ходить на диск. skip-name-resolve убирает обратный DNS-резолв на каждом подключении — с медленным резолвером это 20–100 мс.

PHP-FPM: размер пула, лимиты и OPcache

Главный параметр — pm.max_children: его не угадывают, а считают от реального веса воркера:

ps --no-headers -o rss -C php-fpm8.3 | awk '{s+=
Развернуть за пару минут
Готовый образ на VPS MAATRIX: NVMe, AMD EPYC, root-доступ. Локации UK, США, Франция и РФ. Оплата картой РФ и по СБП.
Развернуть WordPress
База данных: пользователь, коллация и настройки под 2 ГБ
Закройте свежую установку скриптом mariadb-secure-installation — в MariaDB 11.x это новое имя mysql_secure_installation. Заходите как sudo mariadb: попытка mysql -u root -p из-под обычного пользователя даёт
ERROR 1698 (28000): Access denied for user 'root'@'localhost'
Это не «неверный пароль»: root в MariaDB на Debian и Ubuntu аутентифицируется плагином unix_socket, по системному пользователю, и пароль тут не участвует.
CREATE DATABASE wp_main CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'wp_main'@'localhost' IDENTIFIED BY 'СГЕНЕРИРОВАННЫЙ_ПАРОЛЬ';
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, ALTER, INDEX,
      CREATE TEMPORARY TABLES ON wp_main.* TO 'wp_main'@'localhost';
Пароль — из openssl rand -base64 24. Вместо GRANT ALL — перечисленный набор: WordPress не нужны FILE, PROCESS и SUPER, и это сужает ущерб от инъекции. Коллацию задавайте явно: в новых ветках MariaDB умолчание для utf8mb4 другое, и если залить дамп со старого хостинга в базу, созданную «как получится», на первом же JOIN получите Illegal mix of collations (utf8mb4_uca1400_ai_ci,IMPLICIT) and (utf8mb4_unicode_ci,IMPLICIT) for operation '='.
Тюнинг — в /etc/mysql/mariadb.conf.d/60-wordpress.cnf, чтобы его не затёрло обновление пакета:
[mysqld]
skip-name-resolve
innodb_buffer_pool_size = 384M
innodb_log_file_size = 128M
innodb_flush_method = O_DIRECT
max_connections = 60
Буферный пул — память, где живут таблицы: база блога на 5000 записей весит 150–400 МБ, и держать её в RAM дешевле, чем ходить на диск. skip-name-resolve убирает обратный DNS-резолв на каждом подключении — с медленным резолвером это 20–100 мс.
PHP-FPM: размер пула, лимиты и OPcache
Главный параметр — pm.max_children: его не угадывают, а считают от реального веса воркера:
ps --no-headers -o rss -C php-fpm8.3 | awk '{s+=$1; n++} END {print s/n/1024" MB, "n" proc"}'
Чистый WordPress с десятком плагинов даёт 45–70 МБ на процесс, Elementor — 120–160 МБ, WooCommerce — 90–140 МБ. Из общей памяти вычитаете MariaDB, Nginx и систему, остаток делите на средний RSS: на 4 ГБ это (4096 − 700 − 150 − 250) / 70 ≈ 42, но впритык брать нельзя — ставьте 20–25.
pm = ondemand
pm.max_children = 12
pm.process_idle_timeout = 20s
pm.max_requests = 500
php_admin_value[memory_limit] = 256M
php_admin_value[upload_max_filesize] = 64M
php_admin_value[post_max_size] = 64M
Это /etc/php/8.3/fpm/pool.d/www.conf. Режим ondemand поднимает воркер под запрос и гасит через 20 секунд простоя: против dynamic, держащего процессы вхолостую, это сотни мегабайт экономии. Цена честная: первый запрос после паузы дольше на 30–80 мс, поэтому магазину с ровным трафиком нужен static. Заниженный max_children виден в /var/log/php8.3-fpm.log, а посетители получают подвисания и 504 Gateway Time-Out:
WARNING: [pool www] server reached pm.max_children setting (12), consider raising it
Завышенный — уход в своп и убитая OOM-killer'ом MariaDB в dmesg -T. OPcache задайте в /etc/php/8.3/fpm/conf.d/99-wordpress.ini: opcache.memory_consumption=192, opcache.max_accelerated_files=20000, opcache.revalidate_freq=2, opcache.jit_buffer_size=0. Число 20000 не с потолка: find /var/www/example.ru -name '*.php' | wc -l на сайте с двумя десятками плагинов даёт 9–15 тысяч файлов, а при меньшем лимите часть кода компилируется заново на каждом запросе.
Серверный блок Nginx для WordPress
Файл /etc/nginx/sites-available/example.ru.conf — рабочий минимум и замена всему, что жило бы в .htaccess:
server {
    listen 80;
    server_name example.ru www.example.ru;
    root /var/www/example.ru;
    index index.php;
    client_max_body_size 64M;

    location / {
        try_files $uri $uri/ /index.php$is_args$args;
    }

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
        fastcgi_read_timeout 120s;
    }

    location ~* /(?:wp-config\.php|readme\.html|license\.txt)$ { deny all; }
    location ~* ^/wp-content/uploads/.*\.(?:php|phtml|php[0-9])$ { deny all; }
}
Три места, которые чаще всего пишут неправильно:
try_files $uri $uri/ /index.php$is_args$args; — это и есть ЧПУ: Nginx ищет файл, потом каталог и лишь затем зовёт index.php.
include snippets/fastcgi-php.conf; — в сниппете Debian и Ubuntu лежат fastcgi_split_path_info, проверка try_files $fastcgi_script_name =404; и, главное, include fastcgi.conf;. Именно fastcgi.conf, а не похожий fastcgi_params: первый задаёт SCRIPT_FILENAME, второй нет. Подмените одно другим — браузер покажет File not found., а в логе появится FastCGI sent in stderr: "Primary script unknown".
Запрет PHP в uploads — не паранойя: типовой взлом через дырявый плагин заканчивается файлом wp-content/uploads/2026/08/x.php, а правило превращает его в 403 ещё до PHP.
Активируйте симлинком в sites-enabled, удалите дефолтный сайт и проверьте: nginx -t && systemctl reload nginx. Без проверки reload при ошибке тихо оставит старую версию.
Самый частый 502 на LEMP выглядит в логе так: connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory). Путь к сокету разошёлся с реальностью — актуальный покажет grep -r '^listen' /etc/php/*/fpm/pool.d/. Классика: обновили PHP до 8.4, сокет стал php8.4-fpm.sock, а в конфиге остался прежний.
Установка через WP-CLI, права и SSL
WP-CLI ставит сайт серией команд и не оставляет файлов от чужого пользователя:
curl -sSLo /usr/local/bin/wp https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
chmod +x /usr/local/bin/wp && mkdir -p /var/www/example.ru
chown -R www-data:www-data /var/www/example.ru
cd /var/www/example.ru
sudo -u www-data -H wp core download --locale=ru_RU
sudo -u www-data -H wp config create --dbname=wp_main --dbuser=wp_main \
    --dbpass='ПАРОЛЬ' --dbhost='localhost:/run/mysqld/mysqld.sock' \
    --dbcharset=utf8mb4 --dbcollate=utf8mb4_unicode_ci
sudo -u www-data -H wp core install --url=https://example.ru --title='Мой сайт' \
    --admin_user=ops --admin_password='ПАРОЛЬ' --admin_email=you@example.ru
sudo -u www-data -H wp rewrite structure '/%postname%/'
--dbhost указан через unix-сокет, а не 127.0.0.1: TCP-хендшейк на каждое соединение — мелочь, но на странице с полусотней запросов к базе она набегает. И не берите логин admin: боты начинают перебор именно с него, в access.log это видно потоком POST на /wp-login.php.
Права выставьте явно — каталоги 755, файлы 644, chmod 640 на wp-config.php. Владелец www-data позволяет ставить плагины из админки, но даёт веб-процессу право переписывать собственный код — ровно то, чем пользуется залитый шелл; строгий вариант: владелец deploy, группа www-data, запись только в wp-content/uploads, обновления через wp core update по SSH.
Затем закройте редактор тем и встроенный планировщик: wp config set DISALLOW_FILE_EDIT true --raw, wp config set DISABLE_WP_CRON true --raw, wp config shuffle-salts. Штатный WP-Cron запускается посетителем, поэтому задачи вешают на системный крон: */5 * * * * cd /var/www/example.ru && wp cron event run --due-now.
Сертификат выпускайте после того, как A-запись уже указывает на сервер (dig +short example.ru), иначе Let's Encrypt вернёт Timeout during connect (likely firewall problem):
apt -y install certbot python3-certbot-nginx
certbot --nginx -d example.ru -d www.example.ru --key-type ecdsa --agree-tos -m you@example.ru
Certbot допишет listen 443 ssl; и редирект с 80-го; проверьте, что HTTP/2 включён отдельной директивой http2 on; — синтаксис listen 443 ssl http2; устарел ещё в nginx 1.25.1. Затем поправьте в базе home и siteurl на https://, иначе получите бесконечный редирект или смешанный контент. Есть свободная память — добавьте объектный кеш Redis с плагином redis-cache: на стенде 2 vCPU / 4 ГБ TTFB главной упал с 210 до 130 мс, а списка записей в админке — с 480 до 240 мс.
Какой сервер под WordPress на LEMP взять в MAATRIX
Минимум: 1 vCPU, 2 ГБ RAM, 25 ГБ NVMe. Один сайт — блог, визитка, корпоративная страница — до 800 визитов в сутки. Ограничение честное: 2 ГБ делятся между MariaDB (около 400 МБ с пулом выше), шестью-восемью воркерами PHP по 70 МБ и Nginx. Redis сюда уже не помещается, а тариф на 1 ГБ брать не стоит: формально запустится, но первый же конструктор страниц с его 120–160 МБ на запрос положит сайт.
Комфортный вариант: 2 vCPU, 4 ГБ RAM, 60–80 ГБ NVMe. Помещаются Redis, кеш Nginx, ночной mysqldump без просадки для посетителей и копия сайта под тесты. Для WooCommerce с каталогом до 5000 позиций это старт: корзина и оформление заказа не кешируются в принципе, каждый запрос идёт до PHP и базы, поэтому при живом трафике берите 8 ГБ и 4 vCPU. Растёт со временем только медиатека: блогу 25 ГБ хватает года на два, магазину нужно от 80 ГБ.
Локация — Великобритания, Лондон. Удобна для смешанной аудитории: до Москвы 40–50 мс, до Петербурга 35–45, до Берлина и Амстердама 10–20 мс. Оговорка: если сайт собирает персональные данные граждан России (форма заявки с телефоном — уже персональные данные), 152-ФЗ требует держать первичную базу в РФ, и тогда основной сервер нужен в RU-локации.
Все команды выше нужны при ручной развёртке. При заказе в MAATRIX это не обязательно: WordPress есть в каталоге apps.maatrix.io и ставится на сервер автоматически при оформлении — вместе с Nginx, PHP-FPM и базой, без единой команды с вашей стороны. Автоустановка работает на Ubuntu и Debian, а адрес сайта, логин и пароль администратора появятся в личном кабинете, в разделе «Доступ». Пул PHP-FPM, лимиты загрузки и правила Nginx вы после этого правите под свой проект уже на работающем сайте. Оплата — картой российского банка, по СБП, криптовалютой или токеном MAAT: зарубежная карта для британской площадки не нужна.
Развернуть за пару минут
Готовый образ на VPS MAATRIX: NVMe, AMD EPYC, root-доступ. Локации UK, США, Франция и РФ. Оплата картой РФ и по СБП.
Развернуть WordPress
; n++} END {print s/n/1024" MB, "n" proc"}'

Чистый WordPress с десятком плагинов даёт 45–70 МБ на процесс, Elementor — 120–160 МБ, WooCommerce — 90–140 МБ. Из общей памяти вычитаете MariaDB, Nginx и систему, остаток делите на средний RSS: на 4 ГБ это (4096 − 700 − 150 − 250) / 70 ≈ 42, но впритык брать нельзя — ставьте 20–25.

pm = ondemand
pm.max_children = 12
pm.process_idle_timeout = 20s
pm.max_requests = 500
php_admin_value[memory_limit] = 256M
php_admin_value[upload_max_filesize] = 64M
php_admin_value[post_max_size] = 64M

Это /etc/php/8.3/fpm/pool.d/www.conf. Режим ondemand поднимает воркер под запрос и гасит через 20 секунд простоя: против dynamic, держащего процессы вхолостую, это сотни мегабайт экономии. Цена честная: первый запрос после паузы дольше на 30–80 мс, поэтому магазину с ровным трафиком нужен static. Заниженный max_children виден в /var/log/php8.3-fpm.log, а посетители получают подвисания и 504 Gateway Time-Out:

WARNING: [pool www] server reached pm.max_children setting (12), consider raising it

Завышенный — уход в своп и убитая OOM-killer'ом MariaDB в dmesg -T. OPcache задайте в /etc/php/8.3/fpm/conf.d/99-wordpress.ini: opcache.memory_consumption=192, opcache.max_accelerated_files=20000, opcache.revalidate_freq=2, opcache.jit_buffer_size=0. Число 20000 не с потолка: find /var/www/example.ru -name '*.php' | wc -l на сайте с двумя десятками плагинов даёт 9–15 тысяч файлов, а при меньшем лимите часть кода компилируется заново на каждом запросе.

Серверный блок Nginx для WordPress

Файл /etc/nginx/sites-available/example.ru.conf — рабочий минимум и замена всему, что жило бы в .htaccess:

server {
    listen 80;
    server_name example.ru www.example.ru;
    root /var/www/example.ru;
    index index.php;
    client_max_body_size 64M;

    location / {
        try_files $uri $uri/ /index.php$is_args$args;
    }

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
        fastcgi_read_timeout 120s;
    }

    location ~* /(?:wp-config\.php|readme\.html|license\.txt)$ { deny all; }
    location ~* ^/wp-content/uploads/.*\.(?:php|phtml|php[0-9])$ { deny all; }
}

Три места, которые чаще всего пишут неправильно:

• try_files $uri $uri/ /index.php$is_args$args; — это и есть ЧПУ: Nginx ищет файл, потом каталог и лишь затем зовёт index.php.
• include snippets/fastcgi-php.conf; — в сниппете Debian и Ubuntu лежат fastcgi_split_path_info, проверка try_files $fastcgi_script_name =404; и, главное, include fastcgi.conf;. Именно fastcgi.conf, а не похожий fastcgi_params: первый задаёт SCRIPT_FILENAME, второй нет. Подмените одно другим — браузер покажет File not found., а в логе появится FastCGI sent in stderr: "Primary script unknown".
• Запрет PHP в uploads — не паранойя: типовой взлом через дырявый плагин заканчивается файлом wp-content/uploads/2026/08/x.php, а правило превращает его в 403 ещё до PHP.

Активируйте симлинком в sites-enabled, удалите дефолтный сайт и проверьте: nginx -t && systemctl reload nginx. Без проверки reload при ошибке тихо оставит старую версию.

Самый частый 502 на LEMP выглядит в логе так: connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory). Путь к сокету разошёлся с реальностью — актуальный покажет grep -r '^listen' /etc/php/*/fpm/pool.d/. Классика: обновили PHP до 8.4, сокет стал php8.4-fpm.sock, а в конфиге остался прежний.

Установка через WP-CLI, права и SSL

WP-CLI ставит сайт серией команд и не оставляет файлов от чужого пользователя:

curl -sSLo /usr/local/bin/wp https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
chmod +x /usr/local/bin/wp && mkdir -p /var/www/example.ru
chown -R www-data:www-data /var/www/example.ru
cd /var/www/example.ru
sudo -u www-data -H wp core download --locale=ru_RU
sudo -u www-data -H wp config create --dbname=wp_main --dbuser=wp_main \
    --dbpass='ПАРОЛЬ' --dbhost='localhost:/run/mysqld/mysqld.sock' \
    --dbcharset=utf8mb4 --dbcollate=utf8mb4_unicode_ci
sudo -u www-data -H wp core install --url=https://example.ru --title='Мой сайт' \
    --admin_user=ops --admin_password='ПАРОЛЬ' --admin_email=you@example.ru
sudo -u www-data -H wp rewrite structure '/%postname%/'

--dbhost указан через unix-сокет, а не 127.0.0.1: TCP-хендшейк на каждое соединение — мелочь, но на странице с полусотней запросов к базе она набегает. И не берите логин admin: боты начинают перебор именно с него, в access.log это видно потоком POST на /wp-login.php.

Права выставьте явно — каталоги 755, файлы 644, chmod 640 на wp-config.php. Владелец www-data позволяет ставить плагины из админки, но даёт веб-процессу право переписывать собственный код — ровно то, чем пользуется залитый шелл; строгий вариант: владелец deploy, группа www-data, запись только в wp-content/uploads, обновления через wp core update по SSH.

Затем закройте редактор тем и встроенный планировщик: wp config set DISALLOW_FILE_EDIT true --raw, wp config set DISABLE_WP_CRON true --raw, wp config shuffle-salts. Штатный WP-Cron запускается посетителем, поэтому задачи вешают на системный крон: */5 * * * * cd /var/www/example.ru && wp cron event run --due-now.

Сертификат выпускайте после того, как A-запись уже указывает на сервер (dig +short example.ru), иначе Let's Encrypt вернёт Timeout during connect (likely firewall problem):

apt -y install certbot python3-certbot-nginx
certbot --nginx -d example.ru -d www.example.ru --key-type ecdsa --agree-tos -m you@example.ru

Certbot допишет listen 443 ssl; и редирект с 80-го; проверьте, что HTTP/2 включён отдельной директивой http2 on; — синтаксис listen 443 ssl http2; устарел ещё в nginx 1.25.1. Затем поправьте в базе home и siteurl на https://, иначе получите бесконечный редирект или смешанный контент. Есть свободная память — добавьте объектный кеш Redis с плагином redis-cache: на стенде 2 vCPU / 4 ГБ TTFB главной упал с 210 до 130 мс, а списка записей в админке — с 480 до 240 мс.

Какой сервер под WordPress на LEMP взять в MAATRIX

Минимум: 1 vCPU, 2 ГБ RAM, 25 ГБ NVMe. Один сайт — блог, визитка, корпоративная страница — до 800 визитов в сутки. Ограничение честное: 2 ГБ делятся между MariaDB (около 400 МБ с пулом выше), шестью-восемью воркерами PHP по 70 МБ и Nginx. Redis сюда уже не помещается, а тариф на 1 ГБ брать не стоит: формально запустится, но первый же конструктор страниц с его 120–160 МБ на запрос положит сайт.

Комфортный вариант: 2 vCPU, 4 ГБ RAM, 60–80 ГБ NVMe. Помещаются Redis, кеш Nginx, ночной mysqldump без просадки для посетителей и копия сайта под тесты. Для WooCommerce с каталогом до 5000 позиций это старт: корзина и оформление заказа не кешируются в принципе, каждый запрос идёт до PHP и базы, поэтому при живом трафике берите 8 ГБ и 4 vCPU. Растёт со временем только медиатека: блогу 25 ГБ хватает года на два, магазину нужно от 80 ГБ.

Локация — Великобритания, Лондон. Удобна для смешанной аудитории: до Москвы 40–50 мс, до Петербурга 35–45, до Берлина и Амстердама 10–20 мс. Оговорка: если сайт собирает персональные данные граждан России (форма заявки с телефоном — уже персональные данные), 152-ФЗ требует держать первичную базу в РФ, и тогда основной сервер нужен в RU-локации.

Все команды выше нужны при ручной развёртке. При заказе в MAATRIX это не обязательно: WordPress есть в каталоге apps.maatrix.io и ставится на сервер автоматически при оформлении — вместе с Nginx, PHP-FPM и базой, без единой команды с вашей стороны. Автоустановка работает на Ubuntu и Debian, а адрес сайта, логин и пароль администратора появятся в личном кабинете, в разделе «Доступ». Пул PHP-FPM, лимиты загрузки и правила Nginx вы после этого правите под свой проект уже на работающем сайте. Оплата — картой российского банка, по СБП, криптовалютой или токеном MAAT: зарубежная карта для британской площадки не нужна.

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