Symfony на VPS: production checklist для PHP-FPM, OPcache и Redis

Symfony-проект редко ломается из-за самого Symfony. Чаще он ломается из-за неправильного PHP-стека на VPS: разные версии PHP в консоли и в PHP-FPM, не очищен prod cache, OPcache держит старый код, Redis открыт наружу, Composer поставил dev-зависимости, Doctrine migrations запущены без backup, а Nginx смотрит не в ту директорию public/.

Типовая боль после первого деплоя выглядит так: локально всё работает, на VPS белый экран или 500 ошибка; после обновления кода сайт показывает старую версию; Symfony пишет в var/cache/prod, но PHP-FPM не имеет прав; assets не обновились; composer install съел всю RAM; Redis “ускорили”, но он начал падать по памяти; после reboot сайт не поднялся, потому что PHP-FPM, worker или queue consumer не были оформлены как сервисы.

Эта статья — практический checklist для размещения Symfony app на VPS: что проверить до заказа, как не сломать production при deploy, когда нужен OPcache, когда Redis действительно помогает и когда VPS уже лучше заменить отдельным сервером.

Когда Symfony app нормально размещать на VPS

VPS подходит для Symfony-приложения, если это сайт, API, CRM, личный кабинет, SaaS MVP, Symfony backend, e-commerce, админка, внутренний сервис, проект на API Platform, сервис с Doctrine ORM, Messenger workers или обычное PHP-приложение с базой данных.

Нормальная production-схема для Symfony на VPS обычно такая:

Nginx принимает HTTP/HTTPS-запросы и направляет PHP-запросы в PHP-FPM.
PHP-FPM исполняет Symfony-приложение.
OPcache кэширует скомпилированный PHP-код в памяти и снижает лишнюю нагрузку на CPU.
Composer устанавливает production-зависимости без dev-пакетов.
Symfony cache прогревается в prod окружении.
Doctrine migrations применяются контролируемо, после backup.
Redis используется для cache, sessions, locks, rate limits или Messenger transport, если он реально нужен.
systemd держит PHP-FPM, Redis и workers в рабочем состоянии после reboot.
backup и monitoring защищают базу, media/uploads, конфиги, очередь задач и SSL.

Для Symfony-проекта можно выбрать VPS Hostyrex: https://hostyrex.net/ru/vps.html. Если конфигурация понятна, тарифы доступны в WHMCS: https://client.hostyrex.net/store/vps.

Что люди реально ищут, когда Symfony не взлетел на VPS

Пользователь обычно не ищет “лучший VPS для Symfony” с первого раза. Он ищет конкретную проблему:

Symfony на VPS Nginx PHP-FPM
Symfony production deploy checklist
Symfony 500 error prod cache
Symfony cache clear prod не помогает
Symfony OPcache показывает старый код после deploy
Symfony var/cache permission denied
Symfony Redis cache adapter как настроить
Symfony Messenger Redis production
Symfony Doctrine migrations production
Symfony Composer install killed out of memory
Symfony assets not found production
Nginx Symfony PHP-FPM 502 Bad Gateway

Значит статья должна отвечать не “как купить сервер”, а “почему проект сломался и как выбрать VPS, чтобы не переделывать стек через неделю”.

Главная ошибка: считать Symfony обычным PHP-сайтом

Symfony нельзя нормально запускать как случайный PHP-скрипт, просто скопировав файлы в web-root. У Symfony есть окружение, cache, compiled container, Composer dependencies, Doctrine migrations, assets, CLI-команды, workers, logs и права на директории var/.

Если на shared-хостинге можно иногда “залить файлы и открыть index.php”, то на VPS под Symfony нужен полноценный PHP stack. Иначе начинаются типовые проблемы: web-сервер смотрит не в public/, PHP-FPM работает от другого пользователя, cache прогрет под root, Composer поставил dev-пакеты, OPcache держит старые файлы, а Redis доступен из интернета.

Правильная схема Nginx + PHP-FPM для Symfony

Для Symfony document root должен указывать на директорию public/, а не на корень проекта. Это частая и опасная ошибка. Если Nginx смотрит в корень проекта, наружу могут стать доступны файлы, которым там не место: .env, composer.json, var/, служебные директории и конфигурация.

Правильная логика такая:

домен указывает на VPS;
Nginx принимает запрос;
корень сайта — /var/www/project/public;
обычные файлы отдаются напрямую;
PHP-запросы передаются в PHP-FPM;
Symfony получает запрос через public/index.php.

Если после настройки вы видите 404, 403, скачивание PHP-файла вместо исполнения или 502 Bad Gateway — почти всегда проблема в связке Nginx, PHP-FPM, пути к socket, версии PHP или правах.

502 Bad Gateway: это не всегда “VPS упал”

502 Bad Gateway в Symfony на VPS обычно значит, что Nginx жив, но не может нормально передать запрос в PHP-FPM.

Типовые причины:

PHP-FPM не запущен.
Nginx настроен на socket от другой версии PHP.
PHP-FPM слушает TCP-порт, а Nginx пытается подключиться к Unix socket.
Неправильные права на socket.
PHP-FPM pool работает от пользователя, у которого нет доступа к проекту.
Процесс PHP-FPM убит из-за нехватки RAM.
Composer или Symfony cache создали файлы от root, а PHP-FPM не может их читать или писать.

Диагностику нужно начинать с логов, а не с переустановки сервера:

systemctl status php8.3-fpm
journalctl -u php8.3-fpm -n 100 --no-pager
nginx -t
tail -n 100 /var/log/nginx/error.log
tail -n 100 var/log/prod.log

Если в логах есть Permission denied, Primary script unknown, connect() to unix socket failed, Allowed memory size exhausted или ошибки Symfony container — это не “плохой VPS”. Это неправильно собранный production stack.

PHP CLI и PHP-FPM: частая ловушка

Одна из самых неприятных проблем: в консоли у вас один PHP, а сайт работает через другой PHP-FPM. Например, php -v показывает PHP 8.3, а Nginx отправляет запросы в php8.2-fpm. В итоге в CLI всё работает, Composer ставится, cache очищается, а сайт падает.

Перед deploy проверьте:

php -v
php -m
which php
systemctl status php8.3-fpm
ls -la /run/php/
nginx -T | grep fastcgi_pass

Важно, чтобы CLI-версия PHP и PHP-FPM-версия были совместимы с проектом. Также проверьте расширения: intl, mbstring, xml, curl, zip, pdo_pgsql или pdo_mysql, redis, opcache. Symfony может проходить часть команд в CLI, но падать в web, если нужное расширение установлено только для одной версии PHP.

Composer на VPS: почему deploy может убить сервер по RAM

На форумах и в реальных тикетах часто повторяется одна история: пользователь берёт маленький VPS, запускает composer install, процесс зависает или получает Killed. Обычно это OOM killer — серверу не хватило RAM.

Для Symfony production лучше не запускать composer update на сервере. update меняет зависимости и может привести к непредсказуемому результату. На сервере обычно нужен composer install по уже зафиксированному composer.lock.

Для production deploy чаще используют такую логику:

composer install --no-dev --optimize-autoloader

Если проект крупный, а VPS маленький, зависимости лучше собирать в CI/CD или на build-сервере, а на production отправлять уже подготовленный release. Иначе в момент deploy VPS может тратить ресурсы не на пользователей, а на сборку vendor-директории.

APP_ENV=prod и APP_DEBUG=0: без этого Symfony не production

Symfony в production должен работать в prod окружении и без debug. Если приложение работает только с APP_DEBUG=1, значит оно не готово к production.

Проверьте:

APP_ENV=prod
APP_DEBUG=0
APP_SECRET не лежит публично и не совпадает с dev-окружением
database DSN вынесен из Git
Redis DSN вынесен из Git
mail/API/payment keys вынесены из Git
.env.local не доступен из web
Nginx смотрит только в public/

Отдельная ловушка: переменные окружения могут быть видны в SSH, но не видны PHP-FPM. Если вы проверили echo $DATABASE_URL в терминале, это ещё не значит, что PHP-FPM видит эту переменную. Для production лучше использовать понятную схему env-файлов, systemd/PHP-FPM pool config или секреты в рамках вашего deploy-процесса.

Symfony cache: почему “я очистил cache, но ничего не изменилось”

В Symfony production cache — это не мелочь. Там compiled container, маршруты, конфигурация, Twig cache и часть оптимизированной структуры приложения. Если cache прогрет неправильно, сайт может показывать старые assets, старую конфигурацию или падать после deploy.

Типовой порядок после обновления кода:

APP_ENV=prod APP_DEBUG=0 php bin/console cache:clear
APP_ENV=prod APP_DEBUG=0 php bin/console cache:warmup

Проблема в том, что cache часто очищают не тем пользователем. Например, deploy выполнялся от root, а PHP-FPM работает от www-data. В итоге var/cache/prod принадлежит root, PHP-FPM не может туда писать, и приложение падает.

Проверка:

ls -la var/
ls -la var/cache/
ls -la var/log/

Директории var/cache и var/log должны быть доступны пользователю, от которого работает PHP-FPM. Права 777 — плохой способ “лечения”. Это быстрый костыль, который потом превращается в дыру безопасности. Нужно настроить правильного владельца, группу и deploy-процесс.

OPcache: нужен почти всегда, но он же вызывает “старый код после deploy”

OPcache — один из главных элементов производительности PHP-приложения. Он хранит скомпилированный PHP-код в памяти, чтобы PHP не парсил одни и те же файлы на каждом запросе. Для Symfony это особенно важно, потому что framework и vendor-зависимости создают много PHP-файлов.

Но OPcache даёт популярную production-проблему: код обновили, а сайт всё ещё исполняет старую версию. Особенно это заметно при symlink/release-деплоях, когда директория current переключается на новый release, а PHP-FPM продолжает держать старые opcodes.

Что важно понимать:

OPcache для CLI и OPcache для PHP-FPM — не одно и то же.
Команда в терминале не всегда очищает OPcache web-процесса.
При агрессивной настройке opcache.validate_timestamps=0 нужно явно перезагружать PHP-FPM или сбрасывать OPcache после deploy.
Если не следить за OPcache memory, можно получить wasted memory и странное поведение после частых deploy.

Для обычного VPS безопаснее начинать с понятной настройки, а не с экстремального тюнинга. Например, включить OPcache, выделить достаточно памяти, увеличить количество кэшируемых файлов и после deploy перезагружать PHP-FPM:

sudo systemctl reload php8.3-fpm

Базовые параметры, которые обычно проверяют для Symfony:

opcache.enable=1
opcache.memory_consumption=256
opcache.max_accelerated_files=20000
opcache.validate_timestamps=1
opcache.revalidate_freq=2

Для более строгого production можно отключать timestamp validation, но только если deploy-процесс гарантированно делает reload PHP-FPM или корректный OPcache reset. Иначе вы сами создадите проблему “код обновили, сайт не обновился”.

Redis: не магическая кнопка ускорения

Redis часто добавляют в Symfony “потому что так быстрее”. Это слабая логика. Redis помогает, если вы понимаете, что именно туда кладёте: cache, sessions, locks, rate limits, Messenger queues, временные данные или результаты тяжёлых операций.

Redis не заменяет базу данных для обычных бизнес-данных. Он хранит данные в памяти и требует контроля памяти, eviction policy, persistence-настроек и безопасности. Если Redis упал, а вы храните в нём sessions или очередь задач, пользователи могут вылететь из аккаунтов, а фоновые задачи перестанут обрабатываться.

Где Redis полезен в Symfony:

Symfony Cache adapter для app cache.
Sessions, если нужно разделять сессии между несколькими PHP-FPM nodes.
Messenger transport для очередей, если вы понимаете требования к надёжности.
Locks для защиты от параллельного выполнения задач.
Rate limiter для API.
Временный cache для тяжёлых запросов.

Где Redis часто используют неправильно:

Открывают Redis на публичный IP.
Не ставят пароль или ACL.
Не ограничивают память.
Не настраивают maxmemory-policy.
Кладут в Redis критичные данные без понимания persistence.
Используют один Redis для cache, sessions и queues без разделения ключей и без мониторинга.
Думают, что Redis исправит медленные SQL-запросы.

Для одного Symfony app на одном VPS Redis обычно должен слушать localhost или приватный интерфейс, а не весь интернет. Наружу Redis почти никогда не должен быть открыт.

Doctrine migrations: нельзя просто нажать migrate на живой базе

Doctrine migrations в production — отдельная зона риска. На маленьком проекте кажется, что всё просто: php bin/console doctrine:migrations:migrate. На живой базе миграция может заблокировать таблицу, долго создавать индекс, удалить колонку, сломать старый код или упасть на несовместимых данных.

Перед миграциями в production нужен порядок:

Сделать backup базы.
Проверить миграции на staging или копии production-базы.
Посмотреть SQL, который будет выполнен.
Понять, есть ли операции с большими таблицами.
Запускать миграции в контролируемое время.
Иметь rollback-план для кода и базы.

Опасные миграции:

изменение типа колонки на большой таблице;
создание индекса на большой таблице без оценки времени;
удаление поля, которое может использовать старый код;
добавление NOT NULL без значения по умолчанию;
массовые data migrations внутри PHP-кода;
миграции, которые зависят от внешнего API или текущего состояния приложения.

Если база уже большая или приложение не может позволить себе простой, лучше не делать “быстрый deploy с migrate”. Нужна нормальная release-схема: backward-compatible migrations, отдельное окно обслуживания, backup, проверка и возможность отката.

Assets в production: почему CSS/JS не обновились

В Symfony-проектах часто используются AssetMapper, Webpack Encore, Vite или другой frontend build. Проблема возникает, когда код обновили, а assets остались старые. В итоге HTML ссылается на один hash-файл, а на диске лежит другой. Пользователь видит 404 на CSS/JS или старую версию интерфейса.

Что проверить:

production build assets реально выполняется;
директория public/build или аналогичная попадает в release;
manifest-файл соответствует текущей версии assets;
Nginx отдаёт assets из правильной директории;
Symfony cache очищен и прогрет после обновления assets;
OPcache/PHP-FPM не держит старый compiled container.

Если после deploy страницы ссылаются на старые asset-файлы, проблема может быть не в браузерном cache, а в Symfony cache или OPcache.

Права на файлы: не лечите всё chmod 777

Ошибка Permission denied в Symfony чаще всего связана с var/cache, var/log, uploads/media-директорией или release-директорией после deploy.

Плохое решение:

chmod -R 777 var/

Это быстро убирает ошибку, но создаёт плохую security-практику. Правильнее настроить владельца и группу так, чтобы deploy-user и PHP-FPM-user имели нужные права. На VPS это проще сделать системно, чем каждый раз чинить руками после deploy.

Проверьте, от кого работает PHP-FPM:

ps aux | grep php-fpm
grep -R "user =" /etc/php/*/fpm/pool.d/
grep -R "group =" /etc/php/*/fpm/pool.d/

И проверьте владельца проекта:

ls -la /var/www/project
ls -la /var/www/project/var

Symfony Messenger и workers: сайт работает, но задачи не выполняются

Если проект использует Symfony Messenger, очереди, email jobs, imports, exports, webhooks или background tasks, одного PHP-FPM недостаточно. Нужны отдельные workers.

Частая ошибка: developer запускает worker вручную:

php bin/console messenger:consume async

Пока SSH открыт — задачи идут. После закрытия терминала или перезагрузки VPS — всё остановилось. В production workers должны запускаться через systemd, Supervisor или другой process manager.

Также нужно следить за памятью. Долгоживущие PHP workers могут накапливать memory usage. Для Messenger обычно задают лимиты по времени, памяти или количеству сообщений, чтобы worker регулярно перезапускался.

Firewall и безопасность Symfony VPS

Для обычного Symfony production-сервера наружу обычно нужны только:

22/tcp для SSH, лучше с ключами и ограничением доступа;
80/tcp для HTTP и выпуска SSL;
443/tcp для HTTPS.

Не нужно открывать наружу Redis, database, PHP-FPM socket/port, админские панели, debug-инструменты, profiler, internal APIs, RabbitMQ/Redis dashboards, database web UI или monitoring без защиты.

Если проект связан с пользовательским контентом, массовыми регистрациями, mail, scraping, proxy, VPN-функциями, high-risk API или нестандартным трафиком, перед заказом лучше проверить условия использования и abuse policy: https://hostyrex.net/ru/terms.html.

Backup: что именно нужно сохранять

У Symfony-проекта обычно есть несколько важных частей:

код — обычно в Git;
database — PostgreSQL или MySQL/MariaDB;
uploads/media — пользовательские файлы;
.env.local или production secrets;
конфиги Nginx и PHP-FPM;
Redis, если там хранятся не только временные cache-данные;
очереди задач, если потеря сообщений критична.

Код в Git — это не backup проекта. Самое ценное обычно в базе и пользовательских файлах. Перед Doctrine migrations backup обязателен. Перед крупным обновлением Symfony, PHP, Composer-зависимостей или структуры assets — тоже.

Минимальный backup-план:

ежедневный backup базы;
backup uploads/media;
хранение backup вне основного VPS;
retention: несколько копий, а не один перезаписываемый файл;
проверка восстановления на тестовом окружении;
отдельный backup перед миграциями.

Monitoring: что отслеживать у Symfony app

Без monitoring владелец узнаёт о проблеме от клиента. Для production Symfony это слабая позиция.

Минимум, который стоит отслеживать:

доступность сайта по HTTPS;
HTTP 500/502/504;
свободное место на диске;
RAM и swap;
CPU load;
статус PHP-FPM;
статус Nginx;
статус Redis;
статус database;
Symfony var/log/prod.log;
очередь Messenger;
успешность backup;
срок действия SSL-сертификата.

Самая дорогая поломка — не та, где сайт сразу упал. Самая дорогая — когда Redis давно забит, очередь не обрабатывается, backup не создаётся, диск заполнился, а проблему заметили через несколько дней.

Сколько ресурсов VPS нужно для Symfony

Нельзя считать только PHP. На VPS будут Nginx, PHP-FPM workers, OPcache, Composer, database, Redis, queue workers, cron, backup-процессы и monitoring.

Практический ориентир:

1 vCPU / 2 GB RAM — небольшой сайт, тест, staging, простой Symfony-проект без тяжёлой базы и workers.
2 vCPU / 4 GB RAM — нормальный старт для production Symfony app, API, админки, небольшой базы, OPcache и Redis.
4 vCPU / 8 GB RAM — проект с активными пользователями, очередями, Redis, database, регулярными deploy и запасом под Composer/backup.
8+ GB RAM и больше CPU — если есть тяжёлые запросы, много PHP-FPM workers, несколько приложений, активная очередь, большой database или high-load API.

Если Symfony-приложение упирается в database, увеличение PHP-FPM workers может сделать хуже: запросов к базе станет больше, RAM уйдёт быстрее, latency вырастет. Поэтому ресурсы нужно подбирать по реальной архитектуре, а не по принципу “поставим больше workers”.

Что проверить перед заказом VPS под Symfony

Какая версия PHP нужна проекту?
Какие PHP extensions требуются?
Нужен PostgreSQL, MySQL/MariaDB или внешняя база?
Будет ли Redis и для чего именно?
Нужны ли Messenger workers?
Есть ли frontend build: AssetMapper, Encore, Vite, npm/yarn/pnpm?
Сколько RAM нужно на Composer install и cache warmup?
Где будут храниться uploads/media?
Какой backup нужен до migrations?
Кто будет обновлять PHP, Symfony, security patches?
Нужен ли staging?
Какие порты должны быть открыты?
Есть ли требования к IP, локации, routing, abuse policy?

Если проект уже production и есть пользователи, база, uploads или очереди, не заказывайте VPS вслепую. Лучше заранее описать стек, размер базы, нагрузку, Redis, workers, backup и требования к миграции. Связаться с Hostyrex можно здесь: https://hostyrex.net/ru/contacts.html.

Когда VPS не подходит

VPS — нормальный выбор для большинства Symfony-проектов, но не всегда лучший.

Лучше смотреть в сторону dedicated server или отдельной архитектуры, если:

database уже большой и активно пишет на диск;
есть тяжёлые отчёты, imports/exports, аналитика;
много Messenger workers и долгих фоновых задач;
Redis критичен и не должен делить ресурсы с PHP;
нужны гарантированные CPU-ресурсы под постоянную нагрузку;
несколько production-проектов живут на одном узле;
есть high-load API или e-commerce с дорогим простоем;
нужна отдельная сеть, IP-подсеть, BGP или сложный firewall.

В таких случаях лучше рассматривать выделенный сервер: https://hostyrex.net/ru/servers.html. Если проекту нужны отдельные IPv4, RDNS, подсети или сетевые задачи, смотрите страницу IPv4: https://hostyrex.net/ru/ip.html.

Короткий production checklist Symfony на VPS

Document root указывает на public/.
Nginx передаёт PHP-запросы в правильный PHP-FPM socket.
CLI PHP и PHP-FPM совместимы по версии и extensions.
APP_ENV=prod.
APP_DEBUG=0.
Secrets и DSN не лежат в публичном доступе.
composer install --no-dev --optimize-autoloader используется вместо composer update на production.
Symfony cache очищается и прогревается в prod окружении.
var/cache и var/log имеют правильные права без chmod 777.
OPcache включён и учитывается в deploy-процессе.
После deploy делается reload PHP-FPM или корректный OPcache reset.
Redis закрыт от публичного интернета.
Redis имеет memory limit и понятную eviction policy.
Doctrine migrations запускаются только после backup.
Uploads/media не теряются при deploy.
Workers запущены через systemd/Supervisor, а не вручную в SSH.
Firewall открыт только для нужных портов.
SSL установлен и обновляется автоматически.
Backup базы, uploads и конфигов хранится вне VPS.
Monitoring проверяет сайт, PHP-FPM, Redis, database, диск, RAM, SSL и backup.

Как Hostyrex может помочь с Symfony-проектом

Hostyrex предоставляет VPS для Symfony-приложений, PHP API, CRM, e-commerce, backend-сервисов, проектов с Redis, PostgreSQL/MySQL, PHP-FPM, Nginx, OPcache и production-deploy. На VPS можно развернуть полный PHP stack под конкретную задачу: от небольшого сайта до Symfony API с очередями и Redis.

Если требования понятны, можно выбрать VPS здесь: https://client.hostyrex.net/store/vps.

Если проект уже работает у другого провайдера, есть база, uploads, Redis, workers, migrations или риск простоя, лучше сначала описать задачу и согласовать конфигурацию. Для вопросов перед заказом используйте контакты: https://hostyrex.net/ru/contacts.html. Если нужно администрирование или перенос, смотрите managed services: https://client.hostyrex.net/store/managed-services.

FAQ

Можно ли разместить Symfony на VPS?

Да. Symfony нормально работает на VPS, если настроить Nginx, PHP-FPM, OPcache, Composer, prod cache, database, Redis при необходимости, SSL, firewall, backup и monitoring. Просто скопировать файлы в web-root недостаточно.

Что лучше для Symfony: VPS или shared hosting?

Для production-проекта лучше VPS. Symfony часто требует контроля PHP-версии, extensions, Composer, cache warmup, workers, Redis, migrations и Nginx/PHP-FPM. На shared hosting это может быть ограничено.

Почему Symfony показывает 500 error в prod?

Причины: неправильный APP_ENV, включённый debug, нет прав на var/cache или var/log, не установлены production-зависимости, не видны env-переменные, не выполнены migrations, неправильная PHP-версия или отсутствует нужное PHP extension.

Почему после deploy Symfony показывает старый код?

Часто причина в OPcache или Symfony prod cache. PHP-FPM может держать старые opcodes, а Symfony — старый compiled container. После deploy нужно корректно очистить/прогреть cache и перезагрузить PHP-FPM или сбросить OPcache.

Нужен ли OPcache для Symfony?

Да, для production OPcache почти всегда нужен. Без него PHP будет тратить больше ресурсов на повторную обработку PHP-файлов. Но OPcache должен быть учтён в deploy-процессе, иначе возможна проблема старого кода после обновления.

Нужен ли Redis для Symfony?

Не всегда. Redis нужен, если вы используете его для cache, sessions, locks, rate limiter, Messenger queues или временных данных. Если проект маленький, Redis может быть лишней сложностью. Если Redis используется, его нужно закрыть от интернета и настроить лимиты памяти.

Можно ли держать Redis на том же VPS?

Для небольшого проекта — да. Но нужно учитывать RAM. Redis хранит данные в памяти, поэтому без лимитов он может конкурировать с PHP-FPM и database. Для крупных проектов Redis лучше выносить отдельно.

Почему Composer install падает на VPS?

Часто из-за нехватки RAM. На маленьких VPS Composer может быть убит OOM killer. Для production лучше использовать composer install --no-dev --optimize-autoloader, а крупные проекты собирать в CI/CD или на build-сервере.

Можно ли запускать Doctrine migrations автоматически при каждом deploy?

Можно, но осторожно. На маленьких проектах это удобно. На production с живыми пользователями миграции должны запускаться после backup и проверки. Опасные изменения схемы лучше делать в несколько этапов.

Почему Symfony cache clear даёт Permission denied?

Обычно cache создавался от одного пользователя, а PHP-FPM работает от другого. Например, deploy делался от root, а сайт работает от www-data. Нужно исправить владельца и deploy-процесс, а не ставить chmod 777.

Сколько RAM нужно для Symfony VPS?

Для небольшого production Symfony лучше начинать с 2 vCPU и 4 GB RAM. Минимальные VPS подходят для тестов и маленьких сайтов, но Redis, database, Composer, workers и OPcache требуют запаса.

Что спросить у провайдера перед заказом VPS под Symfony?

Уточните CPU/RAM/NVMe, версию ОС, доступ к нужным PHP-версиям и extensions, IPv4, firewall, backup, условия по трафику, managed support, возможность миграции, локацию, route test и правила abuse policy для вашего типа проекта.

Категории