Laravel · Deploy+

Laravel hosting, with a deploy on every push.

PHP 8.3 to 8.5, Composer, Node for Vite, MySQL 8 and Redis, ready to go. You connect the repository and every push publishes a new release with your migrations, with no downtime; if something goes wrong, you go back to the previous one in seconds.
See plans How Deploy+ works
tuapp.com production

Deploy+v42 published

main · a91f3c2 · 3 min ago

  • PHP 8.4 OPcache · Composer 2 ✓
  • MySQL 8 tuapp_prod · 214 MB ✓
  • Redis in-memory cache ✓
  • Scheduler schedule:run · 12 s ago
  • Queues default · 0 pending ✓

PHP 8.1 to 8.5

the version your Laravel needs, per project

Deploy+ included

from GitHub, GitLab, Bitbucket or Gitea

Redis included

cache on every plan; persistent from Avanza

Rollback in seconds

the latest releases stay on the server

Requirements

What a Laravel app needs, without setting up a server.

The requirements in the Laravel documentation, one by one, against what every Hostsuar hosting plan includes.
  • PHP 8.3 or later · Laravel 12: 8.2 From 5.4 to 8.5, with the version you want for each project.
  • Extensions ctype, curl, dom, fileinfo, filter, hash, mbstring, openssl, pcre, pdo, session, tokenizer, xml Available in the PHP selector, along with intl, gd, redis and imagick.
  • Dependencies Composer 2 In your account's terminal and in the Deploy+ script.
  • Assets Node and npm for Vite Node via NVM: Deploy+ installs it first if your script uses it.
  • Database MySQL 8, PostgreSQL or SQLite MySQL 8, and Deploy+ creates the database and writes the .env when you connect the repository.
  • Cache, queues and sessions database by default since Laravel 11 Queues and sessions in your MySQL or, from Avanza, in persistent Redis; for the cache, Redis is included on every plan.
  • Scheduler cron every minute with schedule:run Deploy+ adds it to your cron when it publishes, with your version's PHP.
  • Deployment Git and SSH Deploy+ with a signed webhook; SSH and Git on your account once enabled.

Requirements according to the Laravel documentation.

Deploy+

The last mile, sorted.

Your code is already in Git. Deploy+ takes care of getting it to production the way you would on your own server, with the Laravel profile ready to go.

Deployment

One push, one new release, zero seconds of downtime

Deploy+ clones the commit into its own folder, runs Composer, the Vite build, the migrations and php artisan optimize, and only if everything succeeds does it switch the link that makes it live. If a step fails, the previous release stays online.
signed webhook Laravel profile no downtime

Deploy #42 · main

Laravel profile

› git clone a91f3c2 1,8 s

› composer install --no-dev --optimize-autoloader 12,4 s

› npm ci && npm run build vite 21,0 s

› php artisan migrate --force 0,9 s

› php artisan optimize config · routes · views 1,2 s

releases/42 → current 0 s of downtime

The profile

It knows where public, storage and the .env go

It serves from public, keeps storage and the .env outside the code so they survive every release and, if you tick it, creates the database and writes the connection.

.env + storage

shared between releases; you edit the .env from the panel

Shared between versions

~/deploy/tuapp/

shared/ → releases/20260905-1012/

.enveditable

storage/from the profile

public/uploads/yours

Linked into each new version; a rollback doesn't touch them either.

Scheduler and queues

The scheduler by cron, queues straight away

schedule:run every minute with your app's PHP. From Avanza, your queue worker or Horizon stay running as persistent processes and restart automatically if they go down. On any plan, the scheduler can launch a worker that processes the queue and stops when it's empty.
schedule:run queue:work Horizon persistent processes

A cron line

every minute

* * * * * php ~/tuapp/current/artisan schedule:run

routes/console.php

  • queue:work --stop-when-empty every minute
  • emails:resumen-diario 08:00
  • model:prune 02:00
  • next run

Rollback

Rolling back takes seconds

The history keeps every deployment with its commit, who started it and the full log. The latest releases stay on the server: going back to one doesn't clone anything.

5 versions

kept by default; you decide how many

Deployment history

5 saved versions
DateTriggerTime
today 10:12 · a91f3c2 Push 38 s
yesterday 18:30 · e07b9d4 Manual 41 s
yesterday 11:05 · 4c1d8e7 Rollback 2 s
Mon 09:48 · 4c1d8e7 Push 35 s

yesterday 18:30 · e07b9d4

the version stays on the server

Roll back to this version

The script

The script we recommend for Laravel.

It starts from the one the Laravel profile suggests and adds the migrations. It runs on the new release before publishing it: if a command fails, it isn't published. Afterwards, Deploy+ restarts your persistent workers with the new code.

npm ci && npm run build
only if your app builds assets with Vite; Deploy+ installs Node first
migrate --force
migrations run before publishing, against the production database
optimize
caches the new release's config, routes, views and events; Deploy+ restarts the persistent workers when it publishes it
Deployment script · Laravel profile
  1. 1composer install --no-dev --optimize-autoloader --no-interaction
  2. 2npm ci && npm run build
  3. 3php artisan migrate --force
  4. 4php artisan optimize
Variables, blocked commands and Node, in the Deploy+ guide

Forge, VPS or hosting

Do you need a server for your Laravel app?

For most apps, no. What changes is who manages the server and which processes you can keep running.

  • The server

    A VPS with Forge
    You manage it; Forge configures it
    A VPS by hand
    You set it up and manage it
    Hostsuar
    We manage it

  • Patches and security

    A VPS with Forge
    Your responsibility
    A VPS by hand
    Your responsibility
    Hostsuar
    Our responsibility, with antivirus and isolation

  • Deployment

    A VPS with Forge
    Forge, with your script
    A VPS by hand
    Your own script
    Hostsuar
    Deploy+ included, with rollback

  • Backups

    A VPS with Forge
    Whatever you configure
    A VPS by hand
    Whatever you configure
    Hostsuar
    80 restore points included

  • Queues and Horizon

    A VPS with Forge
    Yes
    A VPS by hand
    Yes
    Hostsuar
    Yes, running from Avanza

  • WebSockets (Reverb)

    A VPS with Forge
    Yes
    A VPS by hand
    Yes
    Hostsuar
    With a Pusher-compatible service; we help you connect it

  • Octane

    A VPS with Forge
    Yes
    A VPS by hand
    Yes
    Hostsuar
    No: PHP is served by LiteSpeed

  • Support

    A VPS with Forge
    The tool's
    A VPS by hand
    Yours
    Hostsuar
    Engineers who work with Laravel

What doesn't fit is anything that needs its own server in front: Octane, because here PHP is served by LiteSpeed, and Reverb, a server that listens on its own port, which we don't support. For real time, Laravel works out of the box with Pusher and compatible services. Queue workers and Horizon stay running as persistent processes from Avanza: managing a server for that is work you don't need.

Questions

Laravel on hosting, with no small print.

Can I use Laravel queues on shared hosting?

Yes, in two ways. From the Avanza plan, a queue:work or Horizon stays running as a persistent process: it processes each job straight away and, if it goes down, restarts automatically. Avanza allows 3 processes, Max 5 and Elastic 8. On any plan, the scheduler can launch a queue:work --stop-when-empty every minute that processes whatever is pending and exits. Everything counts towards your plan's resources.

Do Horizon, Reverb and Octane work?

Horizon, yes, from the Avanza plan: you keep it running as a persistent process on a persistent Redis, both from the client area. Reverb, not on the hosting itself: it's a server that listens on its own port, and we don't support programs like that. For WebSockets you connect your app to a Pusher-compatible service, such as Pusher Channels or Ably, which Laravel supports out of the box, and we help you connect it. Octane, no: here PHP is served by LiteSpeed, and Octane needs its own application server (Swoole, RoadRunner or FrankenPHP). Livewire, Inertia, Filament, Sanctum, Socialite and Scout work without anything special.

Which PHP version do I need?

Laravel 13 requires PHP 8.3 or later and Laravel 12, PHP 8.2. You have 5.4 to 8.5 and choose it per domain or per folder, so an old app and a new one can live side by side in the same account. On a website published with Deploy+, the version is set in your repository's .htaccess, so it travels with the code on every deployment.

Can I have a staging environment?

Yes. Connect the same repository twice: the main branch to the domain and, for example, develop to staging.tuapp.com, each with its own .env and database. Each push to a branch deploys only to its own site.

Do I get SSH and Composer?

Yes. You enable SSH access from the service options in the client area, and you also have the cPanel built-in terminal, with Git and Composer. And from Deploy+ you can run an artisan command on the published release without opening any terminal.

What if I'm coming from Forge or another host?

You connect the same repository and Deploy+ deploys it the same way; what you need to bring over is the database and whatever you store in storage. If you're coming from another provider, we help you with the move.

Related guides in our documentation

See all documentation →

Your next push, in production.

Every plan comes with Deploy+, Redis and the PHP your Laravel version needs. It was built by people who work with Laravel every day; if you're coming from another provider, we help you bring it over. Plans from 4.10 €/month.
See plans Talk to a technician