Netlify does not run PHP and does not host MySQL. It serves static files and runs JavaScript functions, so a PHP file is delivered to the browser as text and a MySQL connection has nowhere to come from. That is not a configuration problem; it is what the platform is. A PHP and MySQL app has three honest paths: run it as a container on a host that executes PHP with a managed MySQL beside it, split the front end onto a static host and move the PHP behind an API, or, if the app is WordPress, put it on managed WordPress hosting and stop thinking about PHP at all.
The top results for this query are a forum answer from the platform itself saying it cannot be done, a subreddit thread asking where to take the project instead, and a listicle of free hosts that still run PHP. All three are correct and none of them helps you decide. The decision depends on what the PHP app actually is, so this post starts there and then walks each of the three paths far enough to see what it costs.
Table of contents
- The short answer
- What the PHP app actually is
- Path one: keep it PHP, host it where PHP runs
- Path two: split the front end from the PHP
- Path three: it was WordPress all along
- Moving the MySQL database
- How this fits the rest of the stack
- FAQ
The short answer
Netlify’s own support forum puts it plainly: the platform is for modern static sites, and you cannot run PHP at run time. Upload an index.php and the browser receives the source. There is no MySQL either; the platform has since added a managed Postgres product for its serverless functions, which is a JavaScript story, not a PHP one.
This trips people up because the deploy step works. The site builds, the files upload, the URL goes live, and only then does every page render as raw code or a download. If that is where you are, nothing is broken. The app needs a different kind of host, and the next question is which kind.
What the PHP app actually is
Before choosing a path, take inventory. PHP apps fall into a few shapes, and the shape decides the cheapest correct move.
- A site that is only dynamic by habit. Templates included with
include, a contact form, no user accounts. This might be a static site with one form, and the PHP was there because that was the tool on hand. - A real application. Logins, a schema, queries on every request, uploads. Laravel, Symfony, CodeIgniter, or a hand-rolled app that has grown for years. This needs PHP running and a database it can reach.
- WordPress, or a fork of it. Roughly half of the PHP and MySQL apps people try to put on a static host are WordPress installs, and WordPress has its own kind of hosting.
The first shape can sometimes be rebuilt as static files plus a function or a form service, but the last two cannot, and pretending otherwise is how a weekend migration becomes a month. The what is a static website post draws the line between the shapes properly.
Path one: keep it PHP, host it where PHP runs
The least disruptive path for a real application is to leave the code alone and change the host. The modern form of a PHP host is a container: an image with PHP and a web server, built from the repository, with the database as a separate managed service connected over a private network. A minimal Dockerfile for an Apache-flavoured app is short:
FROM php:8.3-apache
RUN docker-php-ext-install pdo pdo_mysql mysqli
RUN a2enmod rewrite
COPY . /var/www/html/
EXPOSE 80The one change worth making in the code is how it finds the database. Hardcoded hosts and passwords in a config file, the pattern the free-host tutorials still show, should become environment variables read at runtime: DB_HOST, DB_NAME, DB_USER, DB_PASSWORD. The environment variables in Docker Compose post covers the local half of that; on a platform the variables are set on the service in the dashboard.
On RunxBuild this path is a Docker service deployed from GitHub with a managed MySQL created beside it. The build log shows the image being built, the live route appears when it starts, and the database is reachable from the service over the private network and from nowhere else by default. A small PHP app runs on the Dev plan at $4 a month (0.3 vCPU, 624MB), Basic at $6 gives it more headroom, and the database has its own plan with scheduled backups and connection limits. The Docker services and databases docs are the two halves of that setup.
Path two: split the front end from the PHP
If most of the site is pages and only a few routes need PHP, there is a case for splitting it: the pages become a static site on a static host, and the PHP shrinks to an API on a small container that the pages call over HTTPS. The static half gets the CDN and the near-zero cost; the dynamic half gets a proper runtime.
The costs are real. Cross-origin requests need CORS headers on the API. Sessions become tokens. Two deployments have to stay in step. It is the right shape for a content site with a login-protected corner, and the wrong shape for an app where every page hits the database. Do not take this path just because the static host is where the project started.
Path three: it was WordPress all along
If the PHP and MySQL app is WordPress, stop evaluating PHP hosts and evaluate WordPress hosts. Managed WordPress hosting handles PHP versions, the database, backups, certificates and updates as a unit, which is exactly the list a container path makes you own. On RunxBuild it starts at $3 a month on the Starter plan, with a file manager and a database browser in the dashboard so plugin repairs and table cleanups do not need SFTP or phpMyAdmin. The managed WordPress post explains what managed covers, and the deploy WordPress in five minutes guide is the setup.
Moving the MySQL database
Whichever path, the data has to move once. The tooling is old and reliable.
- Dump from the old host:
mysqldump -u user -p --single-transaction --default-character-set=utf8mb4 dbname > dump.sql. - Create the managed database and a user on the new host, and note the host, port, name and credentials.
- Import:
mysql -h host -u user -p dbname < dump.sql. For large dumps, run it from a machine close to the database rather than a laptop. - Set the environment variables on the service, deploy, and check the first page that reads from the database.
- Only then point the domain at the new host. Keep the old database read-only until the new one has taken real traffic for a day.
The mysql -u root -p post covers the client commands, and the MySQL to MySQL migration post goes deeper on character sets and large tables, which are the two things that go wrong.
How this fits the rest of the stack
Netlify will not run your PHP, and it was never going to. The app needs a host that executes PHP and a MySQL it can reach privately, which today means a container with a managed database beside it, unless it is WordPress, in which case it means managed WordPress. The RunxBuild hosting calculator puts the PHP service and the database on one page so the monthly figure for the whole app is visible before anything moves. Keep the code, change the host, and put the database password in an environment variable where it should have been all along.
Useful related references:
- Managed WordPress: What the Word Managed Actually Covers, Who It Is For, and What It Should Cost
- MySQL to MySQL: Migrating a Database Between Servers
- PHP Composer: Dependency Management, and the Two Files That Matter
- Docker services on RunxBuild
FAQ
Can Netlify run PHP?
No. Netlify serves static files and runs JavaScript serverless functions. PHP files are delivered to the browser as plain text, and there is no PHP runtime to configure. The platform’s own support forum confirms this. A PHP app needs a host that executes PHP, such as a container service or a managed WordPress host.
Can I use Netlify functions instead of PHP?
Only by rewriting the PHP in JavaScript. Functions run Node or Go handlers, not PHP, so this is a port rather than a configuration change. For a small contact form it is a reasonable trade; for an application with a schema and logins it is a rewrite, and changing hosts is far cheaper.
Is there free hosting for PHP and MySQL?
A few hosts still offer free PHP and MySQL tiers, usually with limits on storage, connections and uptime and with ads or forced subdomains. They are fine for a demo. For anything with users, a small paid container plan with a managed MySQL costs a few dollars a month and includes backups and a private database, which the free tiers do not.
How does a PHP app connect to a managed MySQL?
Through the same PDO or mysqli code it always used, with the host, database name, user and password read from environment variables instead of a config file. The managed database provides a private hostname the service can reach; public access stays off unless you enable it for a specific IP.
Should I rewrite the PHP app in JavaScript to fit Netlify?
Not to fit a host. Rewrite it if there are product reasons; otherwise run the PHP where PHP runs. A working application on the wrong host is a hosting problem with a hosting solution, and the container path keeps the code exactly as it is.