Everything an Artisan deploy needs, unpacked and waiting

That is the expected route. Every plan carries a full SSH shell, so the deploy you run here is the Git workflow you already use locally. Clone from GitHub, GitLab or Bitbucket into your account, run composer install to bring the vendor directory down, and copy your production values into .env. Artisan finishes the setup: php artisan key:generate for the application key, php artisan migrate for the tables. Releases after that are the same handful of commands — git pull for the new commits, composer install if dependencies moved, php artisan migrate for fresh migrations, and a cache clear to drop anything stale. Because this is a real shell rather than a restricted panel, you can tail a log, fix permissions on storage or rerun a command whenever something needs a closer look. Point the document root at the public folder and the app answers over HTTPS.

No. Composer ships with the account and is already on the path, so there is nothing to download, unpack or configure before your first deploy. The moment provisioning finishes, open SSH and composer install, composer update, composer require and composer dump-autoload all run against the correct PHP binary. For Laravel that is the whole game, since the framework and nearly everything you bolt onto it — starter kits, Sanctum, Horizon and the rest — arrive through Composer rather than living in your repository. Your composer.json and composer.lock remain the authority, so the exact versions you tested locally are the versions that end up serving requests. Need Composer running against a particular PHP release? That is covered, because the PHP version is set per site. In short, dependency management on the server works the way it does on your laptop.

Current PHP 8.x releases are stocked, and the control panel lets you set which one each site uses. That choice earns its keep, because every Laravel release names a minimum PHP version — recent ones generally want 8.1 or later, while an older long-term-support project may still be pinned to an earlier 8.x build. Instead of one runtime imposed across the account, you decide per domain, so an ageing client site and a brand-new build can share a plan without treading on each other. Beyond the version itself, the settings Laravel leans on are yours to adjust: memory_limit for heavy Artisan jobs and imports, max_execution_time for anything slow, and OPcache so compiled code stays resident. Switching is instant and reversible, which makes testing an upgrade cheap — try it on a staging domain, confirm the test suite is happy, then move production with one click.

Exactly as the Laravel documentation describes, with nothing platform-specific to learn. For queued work, keep a persistent worker alive with php artisan queue:work so jobs, notifications, mailables and large exports run away from the web request rather than making a visitor wait on a spinner. Back the queue with Redis and those jobs get picked up and cleared quickly even under genuine load. For scheduled work you will not be maintaining a wall of cron lines: everything is registered in Laravel's own scheduler inside your application code, and the server needs exactly one cron entry running php artisan schedule:run every minute. From that single line Laravel decides what is due and runs it, whether that is an hourly digest, a nightly cleanup or a weekly report. After each deploy, run php artisan queue:restart so the workers pick up your new code.

Yes, for cache, sessions and queues — which covers the arrangement most production Laravel apps settle on. Point the cache driver at Redis and expensive query results, rendered fragments and computed values come back from memory instead of being rebuilt on every request. Move sessions across and signed-in users stay quick and consistent as concurrency climbs. Set the queue connection to Redis and jobs are enqueued and processed with very little overhead, so workers keep pace during a rush instead of falling behind. All of it is configured through the ordinary cache, session and queue driver entries in your .env file; nothing custom is required at our end. Because Redis holds this data in RAM rather than on disk, pages that used to feel sluggish tighten up noticeably, and background processing stops backing up the moment traffic spikes.

Yes, and that is how a Laravel app ought to be served. The framework exposes a single entry point inside public, while your application code, .env and storage sit above the web root where nothing can be requested directly. In the control panel you set that domain's document root to the project's public folder, and requests then pass through index.php the way Laravel expects. Layer on free auto-renewing SSL and the app runs over HTTPS with clean URLs and no index.php in the address bar. Setting permissions on storage and bootstrap/cache over SSH is a one-liner, so caching, sessions and uploads behave correctly from the first request. Running several apps on one account? Each domain gets its own document root aimed at its own public folder, keeping the projects cleanly separated while they share the same fast NVMe server.