Laravel hosting shaped around your deploy workflow

Absolutely. Every plan includes a full SSH shell, which means your deploy process looks just like the Git workflow you already use on your own machine. Pull your code from GitHub, GitLab or Bitbucket directly into your account, run composer install to bring in your vendor packages, and copy your live values into .env. Artisan handles the rest: php artisan key:generate creates your app key, and php artisan migrate sets up your database tables. Rolling out a new release afterward is just as simple — git pull for the latest commits, composer install for any dependency changes, php artisan migrate for new migrations, and a quick cache refresh to drop stale config. Since you're working with an actual shell instead of a restricted panel, you're free to tail logs, adjust storage permissions or rerun a command whenever something needs another look. Set your document root to the public folder and your app is live over HTTPS.

No — Composer comes preinstalled on every account and is already on your PATH, so there's nothing for you to fetch, extract or configure before you deploy. As soon as your account is provisioned, open an SSH session and composer install, composer update, composer require and composer dump-autoload all run right away against the correct PHP binary. That's especially useful for Laravel, since the framework itself and most of the packages you'll add — starter kits, Sanctum, Horizon and so on — arrive through Composer rather than living in your repository. Your own composer.json and composer.lock stay in charge, so whatever versions you've tested locally are exactly what ends up on the server. Need Composer to run against a particular PHP release? That's covered too, since PHP version is selectable per site. Your dependency management ends up working just like it does on your local machine.

You get current PHP 8.x releases, and the control panel lets you choose which one each site runs. That choice matters because every Laravel release specifies a minimum PHP version — newer releases typically need PHP 8.1 or later, while an older long-term-support project might still be locked to an earlier 8.x build. Instead of applying one runtime across the board, you set the version per domain, so an aging client project and a fresh build can share the same account without stepping on each other. Beyond the version picker, you can adjust the settings Laravel leans on most: memory_limit for demanding Artisan jobs and imports, max_execution_time for anything long-running, and OPcache so compiled code stays cached in memory. Because switching versions is instant and fully reversible, testing an upgrade carries little risk — try it on a staging domain first, confirm your tests pass, then push production over with one click.

Both work exactly the way Laravel intends. For queued work, keep a persistent worker running with php artisan queue:work so jobs, notifications, mailables and large exports process away from the web request instead of holding up a visitor's page. Pair the queue with Redis and jobs get picked up and cleared quickly even under genuine traffic. For scheduled tasks, you won't be stacking separate cron lines — everything gets registered inside Laravel's own scheduler in your app code, and you add just one cron entry that runs php artisan schedule:run every minute. From that single task, Laravel figures out which commands are due and runs them, whether that's hourly digests, nightly cleanup jobs or weekly reports. After every deploy, run php artisan queue:restart so workers pick up your latest code. It's the standard Laravel approach straight from the documentation, with nothing platform-specific to learn.

Yes — Redis is available for caching, sessions and queues, which covers the setup most production Laravel apps reach for. Switch your cache driver to Redis and expensive query results, rendered partials and computed values get served straight from memory rather than rebuilt on every request. Move session storage over and logged-in users stay fast and consistent as your traffic climbs. Set your queue connection to Redis and background jobs get enqueued and processed with minimal overhead, keeping workers responsive even during a rush. All of this is configured through the standard cache, session and queue driver settings in your .env file — nothing custom is needed on our end. Because Redis holds this data in RAM instead of on disk, pages that once felt sluggish become noticeably quicker, and background processing keeps pace instead of backing up when traffic suddenly spikes.

Yes, and that's exactly how a Laravel app should be served. Laravel keeps a single entry point inside its public directory, while your application code, .env file and storage stay above the web root where nothing sensitive can be reached directly. In the control panel, you point your domain's document root to that project's public folder, and requests pass through index.php the way the framework expects. Add free auto-renewing SSL on top and your app runs over HTTPS with clean, readable URLs and no index.php showing up in the address bar. Setting directory permissions on storage and bootstrap/cache over SSH is straightforward, so caching, sessions and file uploads all work correctly from the start. Running more than one app on the same account? Each domain gets its own document root pointed at its own public folder, keeping every project cleanly separated while they all run on the same fast NVMe server.