PHP & Composer

PHP hosting is its own plan family — PHP Starter and PHP Business. It is not part of a Static or WordPress plan, and PHP sites do not use up your WordPress site allowance. You can hold a PHP plan on its own or alongside another plan.

• PHP 8.3 with pdo_mysql, mysqli, mbstring, bcmath, gd, zip, intl, opcache, exif and pcntl
• nginx in front of php-fpm, in containers dedicated to your site
• A database and database user of your own, on a MariaDB instance kept separate from WordPress
• Automatic SSL and Cloudflare CDN on your subdomain and on any custom domain you connect
• Daily backups, and staging on PHP Business

Your framework is detected from composer.json and its marker files. The framework decides the document root nginx serves and which commands run after each deploy.

Detection runs Laravel first, then Symfony, Craft and Drupal, and falls back to a generic Composer project. What it found is shown on your site's page in the dashboard, and you can override the document root in Site Settings > Build & Deploy.

PHP sites are always deployed from Git — the repository is how your application is installed, so you will be asked for one when you create the site.

1. Subscribe to a PHP plan from Pricing or the Billing page
2. In the dashboard, click Create Site and choose PHP / Laravel
3. Give the site a name and paste your GitHub repository URL
4. Pick a resource tier — small, medium or large
5. Create the site, then trigger the first deployment

Your site is live on its Berican subdomain as soon as the first deploy finishes. Connect a domain you own from Domains whenever you're ready.

Every deployment runs the same sequence on our build host, then ships the built application to your site's container:

1. Clone your repository at the branch and commit you deployed
2. Resolve the app directory — useful when the app lives inside a monorepo
3. composer install --no-dev --optimize-autoloader --no-interaction
4. If the app has a package.json (Laravel Vite, Symfony Encore), also run npm ci and npm run build
5. Ship the built tree to the server, excluding .git and node_modules
6. Run the framework's post-deploy commands inside your PHP container

For Laravel that last step is artisan migrate --force, config:cache, route:cache, view:cache and storage:link. Symfony warms its cache, Craft and Drupal run their migrations.

Set an Install Command or Build Command in Site Settings to replace the Composer and npm steps entirely.

Each PHP site is given its own database and its own database user, on a MariaDB instance separate from the one that serves WordPress. The user's permissions are scoped to that one schema.

This is deliberate. Framework migrations are destructive by nature, so a PHP application must never share a database instance with live WordPress databases, and a migration that goes wrong must not be able to reach past its own schema.

Your credentials are injected as environment variables, so a standard framework config picks them up with no changes:

DB_CONNECTION=mysql
DB_HOST=php-mariadb
DB_PORT=3306
DB_DATABASE=your_site
DB_USERNAME=your_site
DB_PASSWORD=********

Add your own variables — API keys, mail credentials, APP_KEY — under Site Settings > Environment Variables.

Pick the tier that matches your traffic. Reservations are guaranteed headroom; limits are the hard ceiling.

PHP itself runs with a 256M memory limit, 64M uploads, a 300s maximum execution time and opcache enabled. Changing tier is applied to the running containers — no rebuild and no downtime.