Deploy Laravel

Laravel is a PHP web application even when it contains a Vite package.json. Openstead recognizes the Composer manifest and Laravel entry point before applying frontend-only detection.

Select the correct application rootCopy Anchor Link

Choose the directory containing composer.json and artisan. For a standard Laravel application, the public document root is public.

Some packaged PHP applications place Laravel in a nested directory while keeping public assets or index.php elsewhere. Preserve that layout and use a Dockerfile or appropriate server configuration when necessary. Moving only the framework folder can break asset paths, uploads, or the script's existing configuration.

Use the automatic PHP buildCopy Anchor Link

Select Web Service and Railpack. For a conventional Laravel layout, leave the build and start commands empty so the PHP provider handles Composer, browser assets, and the production server together. Do not replace that build with only npm run build.

Declare required PHP extensions through Composer's ext-* requirements. Additional provider-supported extensions can be requested with RAILPACK_PHP_EXTENSIONS. Use a Dockerfile when you need exact PHP packages, production-only Composer installation, a custom public root, or other behavior beyond the provider's defaults.

Configure application secretsCopy Anchor Link

Add these variables to the service, using your actual values:

APP_ENV=production
APP_DEBUG=false
APP_URL=https://your-domain.example
DB_CONNECTION=mysql
DB_HOST=<private-mysql-host>
DB_PORT=3306
DB_DATABASE=<application-database>
DB_USERNAME=<application-user>
DB_PASSWORD=<database-password>
RAILPACK_SKIP_MIGRATIONS=true

Add a stable APP_KEY as a secret. For a new application, generate it once in a trusted local environment:

php artisan key:generate --show

Do not generate a new key on every deployment. When migrating an existing application, preserve its existing key so encrypted data and sessions remain compatible. Enter values in Openstead's Environment page; do not commit the production .env file.

Connect managed MySQLCopy Anchor Link

Create MySQL in the application's permitted private network. Copy its limited application credentials into the web service. 127.0.0.1 points to the application container itself, not a separate managed database.

Set the paid service's Pre-deploy command to:

php artisan migrate --force

The Railpack Laravel provider can run migrations during its default startup. RAILPACK_SKIP_MIGRATIONS=true prevents that behavior so the pre-deploy phase controls them once per release. Do not configure a pre-deploy command on a free web instance; choose a paid web plan for this production setup.

Preserve uploadsCopy Anchor Link

For a standard layout, a persistent disk mounted at /app/storage can retain local application data. Confirm where the actual script writes uploads: some packages use a different assets directory. Persist that exact directory or configure object storage.

Initialize required storage subdirectories and permissions when the mounted disk is empty. Keep bootstrap/cache writable by the runtime user and regenerate configuration caches from runtime variables. Do not mount a data disk over your application source tree.

If the app uses Laravel's public storage link, ensure the link is present in the runtime image or startup procedure. Database backups do not contain uploaded files; plan a separate backup for uploads.

Queues and the schedulerCopy Anchor Link

Deploy queue consumption as a background worker, for example:

php artisan queue:work --sleep=3 --tries=3 --timeout=90

Deploy the Laravel scheduler as a cron job with * * * * * and:

php artisan schedule:run

Use the intended shared database or queue configuration. A worker or cron execution does not automatically share the web service's local upload disk, so jobs that need files should use shared object storage or another explicitly available store.

Migrate an existing licensed scriptCopy Anchor Link

Back up its database, uploaded files, original source, and configuration before migration. Preserve the application key and vendor-provided license or installation files. Use the vendor's supported domain-transfer procedure if the license is tied to a hostname; changing hosts does not justify removing the script's activation checks.

Verify the intended domain, imported data, login, uploads, scheduled tasks, and a representative application action before switching traffic. Redeploy once and confirm that the same uploaded file and database record still exist.