Drop in files. They serve.
Still the shortest path from a script to a URL. No build step, no process to keep alive — a request arrives, your file runs, a page comes back.
index.php is the front door.
Requests land on index.php at the root of what you send. Other .php files are reachable at their own paths, so a small multi-page app works the way it always did, and a framework’s single front controller works too.
If you use Composer, send composer.json and the lock file and leave vendor/ behind — dependencies are installed here, tuned for production. If you don’t use Composer, don’t add one; a folder of PHP files is a complete, valid app.
Configuration your app needs — database credentials, API keys — belongs in the app’s secrets and is read with getenv(), rather than committed in a config file.
index.php lib/format.php styles.css # optional composer.json composer.lock
Everything the platform expects.
Four facts, and they are the complete set — there is nothing else to get right.
composer.json at the root, or .php files with no other runtime’s manifest presentindex.php at the root, served per requestcomposer.json when present — installed for production and optimised. No composer.json is perfectly fine; omit it for a plain PHP app.- build commands
- start commands
- ports
- Dockerfiles
- nginx
- systemd
- process managers
You configure none of this.
There is no build command, no start command and no port setting — for any runtime. Your agent sends files; what runs them is worked out from what's inside.
- TLS renewal
- health checks
- restart policies
- log rotation
- scaling rules
- deploy hooks
- CI pipelines
The one thing each runtime does expect is its entrypoint, and that’s on this page. The deploy reference is the exhaustive version your agent reads.
Will it run what you built?
We'd rather you found out here than mid-deploy, so both halves get the same billing.
Yes — what people deploy here
A single script that does one job · small multi-page sites · form handlers · webhook endpoints · admin and reporting pages · Composer-based projects with a front controller
No — what doesn’t work
Nothing survives between requests on local disk — no file-based sessions you can rely on, no SQLite file that stays put, no uploads directory. Anything that must persist belongs in the database that comes with your app. Long-running worker processes aren’t a fit either, since PHP here runs per request rather than as a daemon.
Why a deploy doesn't come up.
Your agent will usually get these right, and can read the logs when it doesn't. Listed anyway, because knowing the shape of the failure makes the log message make sense.
vendor/ included in the upload.
It makes the upload far larger than it needs to be and can carry paths from your machine. Send the manifests and let the install happen here.
Writing to files and expecting them to stay.
A counter in a text file, a SQLite database, an uploads folder — all of these are gone on the next deploy. This surprises people more than any other PHP limitation.
Credentials in a committed config file.
Put them in the app’s secrets instead and read them with getenv(). They are stored separately from your code and never echoed back to anyone.
Expecting .htaccess rewrites.
Routing that depends on Apache rewrite rules may not behave as it did on shared hosting. Keep paths real, or route inside index.php.
Not what you're building?
Point your agent at it.
€4 a month, database included. Your agent reads the deploy reference itself, so you don't have to.