Laravel hosting built for how you ship

Yes. Every plan comes with a full SSH shell, so deploying is the same Git-based workflow you already use locally. Clone your repository straight from GitHub, GitLab or Bitbucket into your account, run composer install to pull your vendor packages, then copy your production values into .env. From there Artisan takes over: php artisan key:generate sets your app key and php artisan migrate builds your database schema. Shipping a later release is just as quick — git pull to grab the new commits, composer install to update dependencies, php artisan migrate for any new migrations, and a cache refresh to clear the old config. Because you have a real shell rather than a locked-down panel, you can tail logs, fix storage permissions and re-run any command if something needs a second look. Point your document root at the public folder and the site is live over HTTPS.

Yes — Composer is installed on every account and already on your PATH, so there is nothing to download, unpack or configure before your first deploy. Open an SSH session the moment your account is provisioned and composer install, composer update, composer require and composer dump-autoload all work immediately against the correct PHP binary. That matters for Laravel, because the framework and nearly every package you add — from the starter kits to Sanctum, Horizon and the rest — are pulled in through Composer rather than committed to your repository. You keep your own composer.json and composer.lock, so the versions you test locally are the versions that land on the server. If you ever need to run Composer under a specific PHP release you can, since the PHP version is selectable per site. In short, your dependency workflow behaves exactly as it does on your own machine.

You get modern PHP 8.x, and you choose which release each site runs from the control panel. That flexibility matters because every Laravel version states a minimum PHP requirement — recent releases expect PHP 8.1 or newer, while an older long-term-support app may be pinned to an earlier 8.x build. Rather than forcing one runtime on everything, you set the version per domain, so a legacy client project and a brand-new app can live on the same account without conflict. Alongside the selector you can tune the settings Laravel cares about: memory_limit for heavier Artisan commands and imports, max_execution_time for long-running tasks, and OPcache so your compiled code stays hot in memory. Switching versions is instant and reversible, which makes testing a PHP upgrade low-risk — flip a staging domain up first, confirm your test suite passes, then move production across with a single click.

Both are first-class here. For queued work, start a persistent worker with php artisan queue:work so jobs, notifications, mailables and heavy exports run off the web request instead of blocking a visitor's page load. Back the queue with Redis and jobs are picked up and drained quickly even under real traffic. For scheduled work, you do not add a long list of separate cron lines. Instead you register everything inside Laravel's scheduler in your app code, then add one cron entry that runs php artisan schedule:run every minute. From that single task, Laravel decides which commands are due and fires them — hourly digests, nightly clean-ups, weekly reports and so on. After each deploy, run php artisan queue:restart so your workers load the new code. It is the standard Laravel setup working exactly as the documentation describes, with no platform-specific workarounds to learn.

Yes. Redis is available for caching, session storage and queues, which is the combination most production Laravel apps reach for. Point your cache driver at Redis and expensive query results, rendered fragments and computed values are served from memory instead of being rebuilt on every hit. Move sessions onto Redis and logged-in state stays fast and consistent as traffic grows. Set your queue connection to Redis and background jobs are enqueued and processed with very little overhead, so workers stay responsive during spikes. You wire all of this up in your .env with the standard cache, session and queue driver settings — no bespoke configuration is required on our side. Because Redis keeps this working set in RAM rather than on disk, pages that used to feel heavy get noticeably snappier, and background processing keeps up instead of piling into a backlog when a burst of traffic arrives.

Yes, and it is the correct way to serve a Laravel app. Laravel keeps a single entry point in its public directory and holds your application code, .env and storage above the web root, so nothing sensitive is reachable over the web. From the control panel you set your domain's document root to your project's public folder, and requests flow through index.php exactly as the framework intends. Combined with free auto-renewing SSL, your app answers over HTTPS with clean, pretty URLs and no index.php in the address bar. Directory permissions on storage and bootstrap/cache are straightforward to set over SSH, so caching, sessions and file uploads work the first time. If you host several apps on one account, each domain gets its own document root pointed at its own public folder, keeping projects cleanly separated while sharing the same fast NVMe server underneath.