# Laravel, queue workers and scheduler included.

> Managed Laravel hosting. PHP, a queue worker and a managed database run on a dedicated server. CodeHerder ships the changes you brief.

Source: https://customhosted.com/host/laravel/

№ 01 What we host

PHP-FPM, a managed database, a queue worker and the scheduler cron all run on one dedicated instance. A push deploys them. Once the app is here, CodeHerder ships the small feature requests.

When this isn't the right fit Does your Laravel app never queue a job or run a scheduled task? Then it is a slightly smaller shape. Say so on the quote form and the worker line item drops off.

№ 02 The requirements

## What it needs to run

The shape of the workload, before any hosting decision gets made.

- **Runtime**: PHP-FPM, long-running
- **Build step**: Composer install + artisan migrate, run on deploy
- **Standing process?**: Yes: a web process, a queue worker and the scheduler cron
- **Data store**: MySQL or Postgres, via your existing Eloquent migrations
- **Verdict**: Dedicated, budgeted for the worker as well as the web request

№ 03 How it runs

## How it runs here

The same management as every other tier we run, written in Laravel's own terms.

- Provisioning — A dedicated instance with PHP-FPM, a queue worker and the scheduler cron, all set up on day one.
- Deploys — Push to main. The pipeline runs Composer and your migrations, then restarts the web process and the queue worker.
- Data + backups — A managed database tier next to the app, backed up every night with point-in-time recovery. Eloquent migrations run against it unchanged.
- TLS / DNS / monitoring — Certificates renew on their own and we manage DNS end to end. Monitoring restarts a stalled queue worker and alerts a person if it keeps failing. — [What a visitor sees during a restart →](https://customhosted.com/what-visitors-see)

№ 04 Moving it in

## Moving it in

Already running somewhere else? The full [migration playbook](https://customhosted.com/migrate) covers the general steps. Below is what is specific to Laravel.

1. 1 — Point us at the repo — We need read access to the repo and the current database.
2. 2 — We stand up a copy — We run Composer and the migrations, and wire up the queue worker and the scheduler on a staging copy first.
3. 3 — Cutover on your schedule — DNS and TLS switch over with little-to-no downtime. A rollback stays ready if anything looks wrong.

The real gotchas

- Your old host may have run the queue worker on the web server’s box. Here it needs its own line item, or queued jobs never run.
- The scheduler cron (`php artisan schedule:run`) must be in the instance’s crontab. It is easy to move the app and forget the one line that runs it every minute.
- Config caching (`config:cache`, `route:cache`) must run on every deploy. Run it once only and a stale cache survives a code change.

№ 05 The loop

## The loop, on Laravel

Laravel apps grow one feature at a time: a new controller, a queued job, a scheduled report. Each one is a good size for a brief.

1. 01 — Build — CustomLabs — Bring a Laravel app you already built. Or CustomLabs designs and builds the first version to Laravel’s own conventions.
2. 02 — Iterate — CodeHerder — Brief a new controller, a queued job or a scheduled report in plain language. An agent opens a pull request against the real Laravel app.
3. 03 — Run — CustomHosted — PHP-FPM, the queue worker and the scheduler cron on one dedicated instance, with a managed database. We patch it on a schedule.

An example brief

- **The brief**: A queued job that emails a weekly PDF report, plus a scheduler entry that runs it every Monday.
- **What the pull request holds**: The job, the mailable and the scheduler entry, in one pull request the agent opens against the real repo.
- **What happens next**: [A human reviews and merges](https://customhosted.com/review). [It ships through the same pipeline](https://customhosted.com/deploys).
- **A real one**: [The site is blinding at night](https://customhosted.com/case-files#cf-01) (+751 −258 · 19 files · merged 2026-07-31).

№ 06 The queue isn't optional

## The queue worker is part of the app

Laravel makes a job easy to dispatch. The gap we find most often: a host runs the web process and forgets the process that runs the jobs.

Adding `ShouldQueue` to a job class takes two seconds in the editor. In production it is a permanent commitment. From then on, the app has a second process that must run, be monitored, and restart on every deploy. Without it, every queued mailable, notification and background task piles up in a table nobody watches. So we provision the queue worker as part of the app.

The scheduler is a quieter version of the same problem. `php artisan schedule:run` does nothing on its own. Something must call it every minute, and on a fresh instance nothing does until it is in the crontab. An app can look fine in the browser while its reports, cleanup jobs and reminders stay unrun for weeks. See [Background jobs](https://customhosted.com/background-jobs) for how we wire the clock on day one.

None of this changes if the queue driver is Redis, a database table or Horizon. The instance still needs a second process, running all the time, with its own restart policy. That is why the Laravel starting configuration on this page budgets for the worker by default.

№ 07 A starting configuration

## A starting configuration

A production Laravel app: a dedicated instance sized for web and worker, a managed database, and the iteration add-on.

- **Base plan**: Dedicated M
- **Iteration — CodeHerder loop**: +$25/mo
- **Managed database**: DB Standard — +$25/mo
- **Estimated total**: $109/mo

[Get this quoted →](https://customhosted.com/contact?plan=DD-M&addons=AD-CH&db=DB-STANDARD&src=laravel) [Size it differently on the estimator →](https://customhosted.com/#estimate)

№ 08 FAQ

## Laravel questions

The questions this stack raises on its own. General hosting questions live on the homepage.

1. 01 Do you run the queue worker and the scheduler for us? Yes. We set up both when we provision the instance.
2. 02 What if we don’t use queued jobs at all? Then the instance runs lighter and we can size it down. Tell us on the quote form and we leave out the worker process.
3. 03 Can you move an app with Horizon or a Redis-backed queue? Yes. Redis runs next to the app the same way the database does, and the Horizon dashboard keeps working here.
4. 04 Can CodeHerder write Eloquent migrations? Yes. A briefed schema change comes back as a pull request with the migration file in it. Someone reviews it before it runs against real data.
5. 05 Do you support Laravel Octane? Yes, but Octane changes the process model. Tell us if you run it, and we provision a long-lived server process instead of the usual FPM pool.

№ 09 See also

## Keep exploring

- [Databases Managed database tiers, all backed up every night. Point-in-time recovery starts at DB Standard.](https://customhosted.com/databases)
- [Dedicated compute A fixed-price instance sized to the workload, with a static IP and full control.](https://customhosted.com/dedicated)
- [Keep shipping without a dev team The Build → Iterate → Run loop, written as a how-to.](https://customhosted.com/guides/keep-shipping-without-a-dev-team)
- [Email The path your queued job sends mail through, the records it needs, and the limits.](https://customhosted.com/email)

## Ready to start?

Tell us what you're running — one fixed monthly rate, within a business day.

[Get a quote →](https://customhosted.com/contact)