Deploying to a managed Laravel host

[PLACEHOLDER — route to confirm] This guide targets a managed Laravel platform such as [managed Laravel host]. The steps below are written generically; once the recommended host is confirmed, the console-specific steps should be named exactly.

This guide is for the developer or Stellify partner taking an exported Stellify system live. An exported system is standard Laravel — no Stellify runtime, no proprietary dependencies — so it deploys the way any Laravel application does.

What you're deploying

Export the project from Stellify in either of two ways:

• GitHub sync (recommended for ongoing work): the project pushes to a GitHub repository you choose, and subsequent exports commit incrementally to the same repo.
• ZIP download: a one-off archive of the full application.

Either way the export contains a complete Laravel application: app/, routes/, config/, database/migrations/, resources/, a generated composer.json and package.json matched to the capabilities the system uses, a vite.config.js, and a .env.example listing every environment variable the system expects.

Prerequisites

• PHP 8.2 or newer, with Composer
• Node.js and npm (for the Vite front-end build)
• A MySQL or PostgreSQL database
• The export connected to a GitHub repository (most managed hosts deploy from a repo)

Environment variables

Copy .env.example and fill it in. At minimum:

• APP_NAME, APP_ENV=production, APP_DEBUG=false, APP_URL
• APP_KEY — generate with php artisan key:generate
• DB_CONNECTION, DB_HOST, DB_PORT, DB_DATABASE, DB_USERNAME, DB_PASSWORD
• SESSION_DRIVER, CACHE_STORE, QUEUE_CONNECTION — exports default these to database, which needs no extra infrastructure
• MAIL_MAILER and the MAIL_* credentials for your transactional email provider, if the system sends email
• Any provider keys the system's modules use (Stripe, S3, etc.) — each appears in .env.example if the system needs it

Database

Point the DB_* variables at your database, then run the migrations on first deploy:

php artisan migrate --force

Queues and the scheduler

Exports default QUEUE_CONNECTION=database. If the system queues work (emails, jobs), run a worker:

php artisan queue:work --tries=3

Most managed hosts have a first-class way to declare a worker process — use it rather than running one by hand. If the system uses scheduled tasks, ensure the host triggers php artisan schedule:run every minute (managed hosts usually offer a scheduler toggle; on a plain server this is a cron entry).

Mail

Set the MAIL_* variables for your provider and send a test (for example php artisan tinker → Mail::raw('test', fn ($m) => $m->to('you@example.com')->subject('test'));). The system's from-address should be a domain you've verified with your provider.

First deployment

1. Connect the GitHub repository to the host and pick the branch.
2. Set the environment variables above in the host's console.
3. Build steps (most managed hosts run these automatically):

   composer install --no-dev --optimize-autoloader
   npm ci && npm run build
   php artisan migrate --force
   php artisan config:cache && php artisan route:cache && php artisan view:cache
   

4. Point your domain at the deployment and confirm the site loads over HTTPS.

Applying a re-export

As Stellify improves the modules a system is built from, the customer can buy a re-export: a fresh build from the latest module versions against their accepted requirements. GitHub sync commits it to the same repo, so you review the diff like any code change and deploy as usual. IMPORTANT: changes you made to the exported code outside the Studio are not carried across — re-apply them on top of the re-export, treating the merge like any upstream update.