Why a managed PHP runtime beats a raw VPS
On a bare VPS you own the whole stack: OS updates, the PHP-FPM pool, the web server config, TLS renewal, firewall rules, and the database daemon. Any one of them drifting breaks the site, and most of that work has nothing to do with your application. The managed PHP platform gives you a supported PHP 8 runtime with the usual extensions already present, so your responsibility shrinks to the code, its dependencies, and its configuration — the parts that are actually yours.
Framework-friendly for Laravel and Symfony
Modern frameworks expect a specific layout: a public/ document root, a writable storage or var directory, Composer-managed dependencies, and a place to run database migrations on deploy. The platform maps to that directly — you set the document root to public/, keep the rest of the tree private, and wire composer install and artisan/console migration commands into the deploy steps. Redis is available for cache, queues, and sessions, which is exactly what a Laravel queue worker or a Symfony cache pool wants.
Managed MySQL and Redis without being a DBA
Standing up MySQL and Redis yourself means tuning, backups, user management, and keeping them patched. Here both are managed add-ons: you provision them, and their host, port, user, and password are injected into the app's environment rather than pasted into a config file. That keeps secrets out of your Git history, lets you rotate a database password without redeploying code, and means the datastore is maintained separately from your application runtime.
Deploy the way your team already works
Not every PHP project is on Git yet, and that's fine. A small site or a legacy app can be uploaded through the file manager and be live in minutes. A team with a repository connects Git or GitHub and gets push-to-deploy with defined build steps — composer install, a front-end build, migrations — so releases are repeatable instead of an SFTP drag-and-drop that someone forgets a file in. Deploy status and the last deploy time are visible in the panel.
Edge cache and WAF in front of dynamic PHP
PHP applications spend real CPU rendering pages, so serving cacheable responses from the edge directly protects your runtime from load. You decide which routes are safe to cache — a public catalog or article — and which always execute, like a logged-in dashboard or a POST endpoint. The WAF sits at the edge in front of the application, filtering injection and scanner traffic before it reaches PHP, and Auto SSL keeps HTTPS valid without a renewal cron.
A controlled path for modernizing legacy PHP
Old applications written for PHP 5 or an unmaintained CMS are risky to touch, but they can't stay on an end-of-life runtime forever. The platform gives you a place to bring the code, move its database into managed MySQL with the correct character set, and run it on PHP 8 where you can find and fix the deprecations. You validate on a temporary URL and put the WAF in front of a codebase that no longer receives security patches, so the public attack surface is reduced even before the code is fully cleaned up.
How to deploy, step by step
Create the PHP app and pick the runtime
In the panel open Platform, choose PHP, and select the PHP 8 version and plan. The runtime ships with the common extensions PHP apps expect — PDO, mbstring, GD, OpenSSL, and the Redis extension — so you are not filing tickets to get an extension enabled.
Get your code onto the platform
Use the built-in file manager for a quick upload, or connect a Git/GitHub repository so a push deploys the app. For framework apps you set the document root to the public/ directory and define the build and migration steps once.
Attach a managed database and Redis
Provision a managed MySQL database and, if the app needs caching, queues, or sessions, a managed Redis instance. Connection values are injected into the runtime as environment variables, so credentials stay out of your committed .env and can be rotated from the panel.
Point the domain and issue Auto SSL
Attach your domain or a name.cdn.com.tr subdomain, and Auto SSL issues and renews the certificate for apex and www. Traffic now reaches the cdn.com.tr edge first, where SSL termination happens before requests are proxied to your PHP runtime.
Set cache, WAF, and deploy steps
Define which routes are cacheable at the edge and which always hit PHP, apply a WAF profile, and lock in the deploy pipeline — for example composer install, an asset build, and database migrations — so every release runs the same steps and finishes with an automatic purge.
Example scenarios
A Laravel app deploys from GitHub with composer install and migrations, uses managed MySQL and a Redis queue, and serves behind Auto SSL and WAF.
An old custom-CMS portal is moved onto PHP 8 with a managed database, put behind the WAF, and modernized route by route without downtime.
A hand-written PHP API runs on the managed runtime with Redis for rate-limit and session state, exposed on a domain with edge SSL termination.
Frequently asked questions
Which PHP extensions are available on the runtime?
The PHP 8 runtime ships with the extensions typical apps depend on — PDO and MySQL drivers, mbstring, GD for image handling, OpenSSL, cURL, and the Redis extension used for cache, sessions, and queues. Because the extension set is standard, Laravel, Symfony, and most Composer packages install without a custom build.
Can I run a Laravel queue worker or scheduled tasks?
Yes. Redis is available as a queue backend, and the platform runs your app on a persistent runtime rather than a per-request sandbox, so background processing and scheduled jobs fit the model. You define the commands as part of the app configuration rather than editing a system crontab on a server you'd otherwise have to manage.
How do database credentials reach my .env without committing secrets?
The managed database and Redis connection details are injected into the runtime environment. Your framework reads them from the environment the way it already reads .env values, so you never commit host, user, or password to Git, and rotating a password in the panel doesn't require a code change.
My app targets PHP 7 — will it run on PHP 8?
Most maintained code runs on PHP 8 with minor adjustments, but PHP 8 removed some deprecated behavior. The right approach is to bring the code onto the platform, run it on a temporary URL, and fix the deprecations you find before switching the domain — the managed runtime gives you a safe place to do exactly that.
Do I set the document root to public/?
Yes. For Laravel, Symfony, and similar frameworks you point the web root at the public/ directory so the rest of the application tree — including .env, vendor, and storage — stays outside the web-served path. Legacy apps that serve from their top-level directory are supported too; you set the root accordingly.
How do I handle file uploads that must survive a redeploy?
The app has a persistent volume for user data, and for media-heavy apps you can offload uploads to object storage and serve them through the CDN instead of the runtime. That keeps deploys fast and stateless, and it means a redeploy or scale event never risks the uploaded files.