You finished the install. The admin loads. Editors want a public URL that does not die when you push a commit. Now you need a hosting choice and a deploy path that fit a normal Laravel app, not a one-click WordPress panel habit.
This guide is about hosting and deploy paths for LaraDashboard. We cover VPS versus managed Laravel-oriented hosts, zero-downtime style deploys, env and secrets, queue workers, the scheduler, builds, shared storage, and SSL. We will not redo staging and CI, email templates, forms/CRM, MCP agents, Livewire admin UX, or CRUD generators.
Disclosure: LaraDashboard is our open-source Laravel admin and CMS. We recommend it when you want posts, roles, modules, and ops tools in one Laravel codebase you deploy like any other Laravel product. We do not invent speed benchmarks or claim official hosting partnerships. Treat vendor names as class examples, not endorsements.
Related reading: staging, tests, and CI for Laravel CMS work, harden a Laravel CMS for production, backups, updates, and patching, what is LaraDashboard, and how to secure a self-hosted Laravel CMS.
The short answer
Hosting is where the PHP process, web server, database, Redis (if you use it), and file storage live. You can rent a raw VPS and wire nginx or Caddy yourself. You can use a managed Laravel-oriented host (Forge-style provisioners, Ploi-class panels, Cloudways-class stacks) that still leaves you owning the app. Shared PHP hosting that only knows `public_html` often fights Laravel. Prefer a host that expects `public/` as the web root.
Deploy is how a git commit becomes running code without leaving editors on a half-updated site. Common shapes: SSH pull plus artisan commands, Forge or Envoyer-style releases with symlinks, CI that builds then ships an artifact, or a panel button that runs your script. Zero-downtime usually means new release directory, shared `.env` and storage, then atomic symlink flip.
LaraDashboard needs what any serious Laravel app needs: correct PHP version and extensions, Composer install, optional front-end build, writable storage and cache, a running queue worker if you queue jobs, `schedule:run` every minute, HTTPS, and secrets that never sit in git. The CMS is not a special snowflake runtime. It is a Laravel admin plus content stack. Deploy it like one.
Pick a hosting shape before you pick a logo
Teams often shop brand names first. Start with the ops load you will accept.
Raw VPS plus nginx or Caddy
You rent a Linux box. You install PHP-FPM, Composer, Node if you build on the server, MySQL or Postgres, and nginx or Caddy. Caddy makes ACME easy. nginx plus Certbot is the classic path.
You own firewall, upgrades, monitoring, and the deploy script. You gain control. You lose time if nobody enjoys Linux. A single VPS can run app, database, and Redis early on. Document the box.
Forge-style and Envoyer-style managed ops
Laravel Forge and similar provisioners turn a VPS into a known Laravel layout: nginx, PHP-FPM, Supervisor for queues, scheduler cron, SSL, and deploy scripts. Envoyer-class tools focus on zero-downtime releases. You still pay for the VPS and the panel recipe.
Fit: teams that want Laravel defaults without writing every Ansible role from scratch. Honest limit: the panel does not replace backups, staging, or knowing what your deploy script runs. See staging, tests, and CI for the gate before production.
Ploi-class and other Laravel-friendly panels
Same idea as Forge-class tooling: provision servers, manage sites, SSL, queues, and deploys from a UI. Feature sets differ. The architectural bet is the same. Treat the server as a Laravel host with `public/` as the docroot, not as a WordPress shared plan.
Cloudways-class and managed app stacks
These hosts sell a managed stack and a panel for scaling, staging clones, and SSL. You still deploy a Laravel app. Read how they handle Supervisor, cron, and persistent disks before you commit.
What to avoid for LaraDashboard
- Hosting that forbids SSH and Composer.
- Docroot fixed to the repo root instead of `public/`.
- No process manager for `queue:work`.
- No way to run the Laravel scheduler.
- FTP-only deploys that skip `composer install` and migrations.
If a sales page only shows WordPress one-clicks, ask about Laravel before you migrate content.
What LaraDashboard needs on any host
Ground this in normal Laravel ops. LaraDashboard is a Laravel application with admin UI, posts, media, roles, and optional modules. Product overview: what is LaraDashboard.
PHP and extensions. Match the version your codebase targets. Enable the usual Laravel extensions. Check the project README when you upgrade PHP.
Composer. Production deploys should run `composer install --no-dev --optimize-autoloader`. Commit the lockfile.
Web root. Point the site at `public/`. Do not expose `.env` or `vendor/`.
Environment file. Production `.env` lives on the server or in a secrets store. Never commit it. Set `APP_ENV=production`, `APP_DEBUG=false`, a strong `APP_KEY`, correct `APP_URL`, and real database, mailer, and queue values. More in harden a Laravel CMS for production.
Storage and cache. `storage/` and `bootstrap/cache/` must be writable. Link `public/storage` when you use the public disk.
Database. MySQL or Postgres with migrations on deploy after a backup.
Queue worker. If you queue mail, media jobs, or module work, run `queue:work` or `queue:listen` under Supervisor or systemd. Restart workers on deploy so they load new code.
Scheduler. Add cron: `* * * * * php /path/to/artisan schedule:run`. Without it, scheduled publish, prune jobs, and module schedules never fire.
SSL. Terminate HTTPS at the proxy or load balancer. Force HTTPS in Laravel when cookies and URLs must be secure. Pair with the habits in how to secure a self-hosted Laravel CMS.
Node build (when needed). If assets come from Vite or Mix, run `npm ci && npm run build` in deploy or CI. Pick one policy and stick to it.
We do not claim an official hosting partner or a latency leaderboard. Your traffic and team skills decide the box.
Deploy paths that keep editors calm
Hosting is the kitchen. Deploy is how you change the menu without closing the restaurant mid-service.
Simple git pull on a VPS
SSH in. `git pull`. `composer install`. Run migrate and config/route/view cache. Restart PHP-FPM or queue workers. Fine for early projects. Downtime risk rises when Composer or migrations are slow. Plan an upgrade path.
Atomic release directories (Forge / Envoyer pattern)
Each deploy lands in a new `releases/` directory. Shared paths hold `.env` and `storage/`. Then the `current` symlink flips. Restart queue workers. Rollback is a symlink flip, with migrate caution. Prefer expand-then-contract migrations so old code can still run briefly.
CI builds the artifact
CI can run tests, Composer, and the front-end build, then ship a tarball or image. Good when you do not want Node on production. Pair with the staging/tests post. Deploy still needs a host script.
Panel "deploy" buttons
Forge, Ploi, Cloudways-class UIs often wrap the same shell steps. Read the script. Add `migrate --force` only when you intend it. Add worker restarts. Do not assume the default script matches LaraDashboard modules you enabled.
What zero-downtime does not mean
It does not mean reckless migrations. It does not mean skipping backups. It does not mean editors never see a maintenance page during a hard cutover. It means you aim for atomic code flips and short or zero 502 windows for typical PHP requests. Database migrations and search index rebuilds still need a plan. Backup habits: backups, updates, and patching.
Env, secrets, and config on deploy
Treat secrets as part of hosting.
- Store production `.env` outside the release directory or inject from a vault.
- Rotate `APP_KEY` only with a plan.
- Use different keys and database passwords per environment.
- After env changes, run `php artisan config:cache`.
- Never commit `.env` or paste it into chat to "fix a deploy."
- If you clone production to staging, rewrite secrets and mailer targets first.
Queues, scheduler, and long-running processes
LaraDashboard modules may send mail, process uploads, or run maintenance.
Workers. Run at least one `queue:work` process when `QUEUE_CONNECTION` is not `sync`. Supervisor is common. Restart workers on deploy so they load new code.
Failed jobs. Read `failed_jobs`. A silent failed mail job looks like a broken CMS to editors.
Scheduler. Cron must run `php artisan schedule:run` every minute. Confirm with `php artisan schedule:list` after deploy.
Octane and similar. Advanced. Most LaraDashboard installs are fine on PHP-FPM.
Shared storage and media
Uploads must survive deploys. On multi-release layouts, share `storage/` across releases. On multiple app servers, use S3-compatible object storage. Run `storage:link` in deploy. If media vanishes after every deploy, your release script is replacing `storage` instead of sharing it.
SSL and HTTPS cutover
Issue certificates with Caddy, Certbot, or the host panel. Set `APP_URL` to the https origin. Enable HTTPS redirect and secure cookies. After DNS changes, check mixed content. Deploy is incomplete without SSL.
Prose cheat sheet: hosting and deploy choices
Use this when someone asks "just put it on shared hosting."
- Control vs time: Raw VPS = control and ops time. Forge/Ploi-class = Laravel defaults with less DIY. Cloudways-class = managed stack; check queue and cron.
- Web root: Laravel needs `public/`.
- Deploy style: git pull is simple and briefly risky. Atomic releases reduce 502 windows.
- Secrets: shared `.env` or vault. Never git.
- Queues and scheduler: production needs workers if you queue; cron must run `schedule:run`.
- Media: shared `storage` or object storage across releases.
- LaraDashboard fit: standard Laravel app. Disclose: we build it; we deploy it like Laravel.
A minimal path you can adopt this month
Week 1: One solid host with SSL and `public/` as docroot. Week 2: Production `.env`, migrations, admin login over HTTPS. Week 3: Automate deploy (Composer, migrate, caches, worker restart) on staging first. Week 4: Supervisor for queues and cron for the scheduler. Pair with staging and CI from the companion post. Rehearse backup restore on a calendar.
Failure cases to plan for
- Docroot is the repo root. `.env` and vendor leak or 404 chaos. Fix the vhost.
- Deploy without worker restart. Jobs run old code. Restart after every release.
- No scheduler cron. "Scheduled publish never fires." Add the one-liner cron.
- storage wiped each release. Media disappears. Share `storage` or use object storage.
- migrate --force on broken backup habits. Take a DB dump first. See the backups guide.
- APP_DEBUG=true in production. Leak stack traces. Set false and cache config.
- Shared hosting without SSH. You cannot run Composer or workers cleanly. Move host class.
FAQ
Can I run LaraDashboard on shared WordPress hosting?
Only if that host gives you the PHP version you need, Composer, the correct docroot, cron, and a way to run queue workers. Many shared plans do not. A small VPS or Laravel-oriented managed host is the usual fit. We do not publish a partner list. Validate the checklist above.
Do I need Forge or Envoyer?
No. They are popular recipes for VPS layout and atomic deploys. A careful shell script and systemd units can do the same job. Choose based on team time, not brand loyalty.
How does this relate to staging and CI?
Hosting and deploy put code on machines. Staging and CI decide whether that code deserves production. Use both. Start here for boxes and scripts. Use staging, tests, and CI for Laravel CMS work for the quality gate.
Does LaraDashboard need a special PHP extension beyond Laravel?
Treat it as a standard Laravel application plus whatever your enabled modules document. Follow the project requirements for your version. No secret hosting agent is required for a normal install.
Final verdict
Pick a host that expects Laravel: `public/` web root, Composer, SSL, cron, and a process manager for queues. Deploy with a repeatable script. Prefer atomic releases when downtime matters. Keep `.env` and `storage` outside the disposable release. Restart workers on every ship. Run the scheduler every minute. LaraDashboard asks to be treated like a Laravel product with admin, content, and modules.
WordPress-style shared hosting habits fight that model. A VPS, a Forge-style or Ploi-class panel, or a Cloudways-class stack can work when they meet the checklist. Disclosure again: we build LaraDashboard, and we recommend it when you want that Laravel CMS model under your own deploy path.
Ready to host and ship your Laravel CMS? Start at laradashboard.com.
