GitHub Pages does not support PHP, and it never will by design: it serves static files directly from a repository, HTML, CSS, JavaScript, and images, with no server-side language of any kind running behind it, which rules out PHP, Node, Python, Ruby, and everything else that needs a process executing on the server. A .php file pushed to a GitHub Pages repository is served as plain text, not executed, which is usually how people discover the limitation: the contact form that worked on the old host just prints its own source code instead of sending an email.
This lays out exactly what GitHub Pages can and cannot do, why the limitation is architectural rather than a missing setting, and the real options depending on what the PHP was actually doing: converting a templated site to fully static, moving just the dynamic parts to somewhere that runs PHP, or splitting the project into a static frontend and a small backend service in whatever language.
Table of contents
- Why GitHub Pages cannot run PHP, specifically
- What GitHub Pages does host well
- If the PHP was just templating: go static
- If the PHP was doing something real: split frontend and backend
- The specific case of a PHP contact form
- When the honest answer is a different static host entirely
- How this fits the rest of the stack
- FAQ
Why GitHub Pages cannot run PHP, specifically
GitHub Pages works by serving files straight out of a repository branch through GitHub’s own content delivery network. When a request comes in for a path, GitHub finds the matching file in the repository and returns its bytes, exactly as committed. There is no application server sitting behind that process, no interpreter invoked per request, and nothing resembling a PHP-FPM or mod_php process anywhere in the chain. Support for PHP is not a missing checkbox in a settings page; it would require an entirely different serving architecture, one where a process executes code on every request instead of returning a file.
The one build step GitHub Pages does run is Jekyll, and it is worth being precise about what that means: Jekyll runs once, when you push, converting templates and content into plain HTML files that then get served the normal static way. It is not a per-request template engine the way PHP is; by the time a visitor’s browser makes a request, Jekyll has already finished and every file it produced is static.
What GitHub Pages does host well
What GitHub Pages does host, and hosts well for the price of free, is genuinely broad: any pre-built static output, whether that came from Jekyll, a completely different static site generator run locally before pushing the build folder, or a hand-written HTML site with no build step at all. Custom domains, HTTPS certificates issued automatically, and a reasonable bandwidth allowance are included without configuration.
The pattern that trips people up is mistaking ‘can host the output of any framework’ for ‘can run any framework’. A React app builds to static HTML, CSS, and JavaScript that runs entirely in the visitor’s browser, and GitHub Pages hosts that output fine, because by the time it is on GitHub Pages there is nothing left to execute server-side. PHP does not have a build step that produces static output in the same way, because PHP’s entire purpose is running per request, not compiling to a fixed artifact ahead of time.
If the PHP was just templating: go static
If the PHP on the old site was mostly templating, includes for a shared header and footer, a loop over a list of products or posts, variables swapped into an HTML shell, that is exactly the job a static site generator does at build time instead of request time. Hugo is a common choice specifically because its build output plugs directly into GitHub Pages with very little extra configuration, and the mental model, templates plus content files producing static HTML, maps closely onto what the PHP includes were already doing.
The migration is mechanical more often than not: PHP includes become the generator’s own partial or layout system, PHP variables pulled from a database become front matter or a data file read at build time, and any PHP loop over rows becomes the generator’s loop over a content collection. The result deploys through the same GitHub Pages workflow as any other static push, with the entire PHP layer gone rather than worked around.
If the PHP was doing something real: split frontend and backend
If the PHP was doing something a build step cannot replace, handling form submissions, checking a database, running authentication, that logic genuinely needs a server process somewhere, and the honest fix is splitting the project rather than forcing GitHub Pages to do something it structurally cannot. The frontend, whatever static output it builds to, stays static and can still live on GitHub Pages or an equivalent static host. The logic that needs to run moves to a small backend service deployed separately, with the frontend calling it over the network the way any single-page app calls an API.
That backend does not have to stop being PHP. A PHP application packaged with PHP-FPM into a Docker image runs as an ordinary Docker service on a platform that supports one, a real and common deployment shape, just not the native, no-configuration PHP runtime GitHub Pages was never going to offer. The one exception worth naming directly: if the PHP in question is WordPress specifically, that is the one PHP surface actually worth running as a managed platform rather than a container maintained by hand, with a file manager and database browser instead of SFTP and phpMyAdmin.
The specific case of a PHP contact form
The single most common reason people search this exact question is a contact form: a working PHP mail() script on the old host, printing its own source instead of sending anything once moved to GitHub Pages. Three honest paths exist, and none of them involve GitHub Pages itself gaining PHP support. A hosted form-backend service accepts the same form POST and handles the email sending, without any server code in your own repository at all, the lowest-effort fix for a form that is genuinely just a form. A small serverless function, on whichever static host offers one, is close to a drop-in swap for the old PHP mail() call. Building a proper small backend service is the right call once the form is doing more than sending one email: storing submissions, triggering a workflow, validating against existing data.
Whichever path fits, the frontend markup for the form itself barely changes; only the action URL and the server-side handling behind it move.
When the honest answer is a different static host entirely
For most projects that land here, the actual decision is short: templating-only PHP goes static with a generator and stays on GitHub Pages, and PHP doing real work becomes its own backend service, deployed separately, possibly still in PHP. The case that genuinely calls for a different static host is a form-only site that would rather not run any backend code at all, where a static host with its own form-handling and redirect rules built in removes even the small serverless function from the picture, at the cost of tying the deploy to that platform’s own conventions instead of a plain repository push.
None of these paths involve waiting for GitHub Pages to add something it was never built to do. The split, static frontend plus a small service for whatever needs a server, is also the shape almost every framework beyond plain PHP ends up in eventually, so it is rarely wasted effort even for a site that outgrows GitHub Pages entirely later.
How this fits the rest of the stack
A PHP contact form and a full PHP backend are different problems wearing the same error message. Once the fix is a real backend service rather than a build-time swap, a Docker service runs a PHP-FPM image the same way it would run any other container, with build logs, environment variables, and a live route instead of an FTP upload, and the RunxBuild hosting calculator prices that service next to the static site that used to be the whole project.
Useful related references:
- PHP Show All Errors: Why the Page Is Blank and How to Fix It
- PHP Composer: Dependency Management, and the Two Files That Matter
- PHP Warnings: What Changed in PHP 8 and Where They Should Go
- Deploying from GitHub on RunxBuild
FAQ
Does GitHub Pages support PHP?
No. GitHub Pages serves static files directly from a repository with no application server behind it, so PHP, along with every other server-side language, never executes. A .php file pushed to a GitHub Pages repository is served as plain text rather than run.
Can I run a PHP contact form on GitHub Pages?
Not as PHP directly. The usual fixes are a hosted form-backend service that accepts the same form submission, a small serverless function on a static host that supports one, or a proper small backend service once the form needs to do more than send a single email.
What can GitHub Pages actually host?
Any pre-built static output: hand-written HTML and CSS, or the build output of a static site generator like Jekyll, Hugo, or a JavaScript framework. Jekyll is the one build step GitHub Pages runs itself, and it produces static HTML files, not a per-request template engine.
How do I convert a PHP site to work on GitHub Pages?
If the PHP was mostly templating, includes, loops over content, a static site generator does the same job at build time instead of request time, with PHP includes becoming the generator’s own layout system. If the PHP was handling real logic like forms or a database, that logic needs to move to a separate backend service instead.
Can a PHP application run on RunxBuild?
Not as a native, no-configuration PHP runtime the way GitHub Pages does static files. A PHP application packaged with PHP-FPM into a Docker image runs as a Docker service. WordPress is the one PHP application with dedicated, managed support, including a file manager and database browser.