Laravel, queue workers and scheduler included.
PHP-FPM, a managed database, a queue worker, and the scheduler cron all run on one dedicated instance, deployed the moment you push — and once it’s here, CodeHerder can ship the small feature requests that used to wait for a spare afternoon.
When this isn't the right fit A Laravel app that never queues anything and has no scheduled tasks is a slightly smaller shape than this page assumes — say so on the quote form and the worker line item drops off the estimate.
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 — 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
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 process, and the scheduler cron all configured on day one — not left as a manual step you forget.
Deploys
Push to main, the pipeline runs Composer and your migrations, then restarts both the web process and the queue worker.
Data + backups
A managed database tier alongside the app, backed up nightly with point-in-time recovery — Eloquent migrations run against it unchanged.
TLS / DNS / monitoring
Certificates auto-renew, DNS is managed end to end, and monitoring restarts a stalled queue worker before jobs pile up unseen.
Moving it in
Already running somewhere else? See the full migration playbook — here's what's specific to Laravel.
- 1
Point us at the repo
Read access to the repo and the current database is the whole ask.
- 2
We stand up a copy
Composer install, migrations, the queue worker, and the scheduler all wired up on a staging mirror before anything is live.
- 3
Cutover on your schedule
DNS and TLS switch over with little-to-no downtime, rollback ready if anything looks wrong.
- A queue worker that was quietly running on the same box as the web server on your old host needs its own explicit line item here, or queued jobs never process.
- The scheduler cron (`php artisan schedule:run`) has to actually be wired into the instance’s crontab — it’s easy to migrate the app and forget the one line that runs it every minute.
- Config caching (`config:cache`, `route:cache`) needs to be part of every deploy, not a one-time step, or a stale cache survives a code change.
The loop, on Laravel
Laravel apps tend to grow feature by feature — a new controller, a queued job, a scheduled report — which is exactly the granularity the loop briefs well.
- 01Build
CustomLabs
Bring a Laravel app you already built, or have CustomLabs design and build the first version against Laravel’s own conventions.
- 02Iterate
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.
- 03Run
CustomHosted
PHP-FPM, the queue worker, and the scheduler cron on one dedicated instance, alongside a managed database, patched on a schedule.
- Brief
- Briefed: add a queued job that generates a weekly PDF report and emails it, plus a scheduler entry to run it every Monday.
- Pull request
- CodeHerder’s agent wrote the job, the mailable, and the scheduler entry against the real repo, opening a pull request the same day.
- Shipped
- Reviewed, merged, and running on the next scheduled push — no separate cron server to configure by hand.
The queue worker isn't an add-on — it's the app
Laravel makes it trivially easy to dispatch a job. Hosting only the web process and forgetting the thing that actually runs those jobs is the most common gap we find.
ShouldQueue on a job class is a two-second decision in the editor and a permanent infrastructure commitment in production — from that moment, the app has a second, independent process that has to be running, monitored, and restarted on deploy, or every queued mailable, notification, and background task silently piles up in a table nobody's watching. We treat the queue worker as a first-class part of the provisioning, not an optional extra you remember to mention.
The scheduler is the quieter version of the same problem: php artisan schedule:rundoes nothing on its own — it has to be invoked every minute by something, and on a fresh instance that "something" doesn't exist until it's wired into the crontab. A Laravel app that looks fine in the browser can have every scheduled report, cleanup job, and reminder silently not running for weeks, because the one line that makes the scheduler tick was never written down anywhere the migration process could see it. See Background jobs for how the clock is wired on day one instead of left as that manual step.
None of this changes if the queue driver is Redis, a database table, or Horizon — the instance still needs a process that isn't the web server, running continuously, with its own restart policy. That's why the typical starting configuration for Laravel on this site budgets for it by default instead of treating it as a later upsell.
A starting configuration
A production Laravel app: a dedicated instance sized for the web process and a 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
Laravel questions
The questions this stack raises on its own. General hosting questions live on the homepage.
01Do you run the queue worker and the scheduler for us?
Yes — both are configured as part of provisioning, not left for you to wire up after the fact.
02What if we don’t use queued jobs at all?
Then the instance runs lighter and we can size down — tell us on the quote form and we won’t budget for a worker process you don’t need.
03Can you move an app with Horizon or a Redis-backed queue?
Yes — Redis runs alongside the app the same way the database does, and Horizon’s dashboard keeps working once it’s hosted here.
04Can CodeHerder write Eloquent migrations?
Yes — a briefed schema change comes back as a pull request including the migration file, reviewed before it runs against real data.
05Do you support Laravel Octane?
Yes, though it changes the process model — tell us if you’re running Octane and we’ll provision for a long-lived server process instead of the usual FPM pool.
Keep exploring
- Databases
Managed database tiers, backed up nightly with point-in-time recovery.
- Dedicated compute
A fixed-price instance sized to the workload, with a static IP and full control.
- Keep shipping without a dev team
The Build → Iterate → Run loop, written as a how-to.
- Email
The mail your queued job actually sends — the path, the records, and the honest limits.
Ready to start?
Tell us what you're running — one fixed monthly rate, within a business day.