Operate

Deployment

Glozr is a self-hosted Laravel app you install on your own infrastructure. The recommended target is a VPS or dedicated server with SSH access and supervisor; Laravel Cloud works too if you prefer a managed PaaS. Shared hosting (cPanel shared, Plesk mutualisé, classic web hosting) is not supported — see below.

Shared hosting is not supported. Glozr's live chat-to-human feature runs on a persistent WebSocket server (Laravel Reverb) which needs to stay alive on a custom port under supervisor. Shared hosting plans don't allow long-running daemons or custom ports, so they cannot deliver the full product.

Hosting requirements

Requirement	Why
VPS or dedicated server (Linux)	Needed to run `supervisor` and bind Reverb to a port.
SSH access with `sudo`	Needed for `artisan`, `composer` (if rebuilding), and installing `supervisor`.
2 GB RAM / 1 vCPU minimum	Comfortable for a single-tenant install up to a few hundred daily conversations. Scale up as volume grows.
HTTPS (Let's Encrypt or other)	WebSockets are upgraded over `wss://` on 443.
Nginx, Caddy, or Plesk	You need to be able to add a reverse-proxy block for the WebSocket route.

Examples of suitable hosts: Infomaniak VPS Cloud entry tier (~€15/mo), Hetzner CX22, DigitalOcean $12 droplet, OVH VPS, any Plesk-on-VPS install. Examples of unsuitable hosts: Infomaniak "Hébergement Web" shared, OVH mutualisé, classic cPanel shared plans.

Overview

A production install is four moving parts: the app process (FrankenPHP under Octane, or plain PHP-FPM behind Nginx), the worker process (Horizon or queue:work), the websocket server (Reverb), and the data layer (MySQL/Postgres + Redis). Everything else — mail, object storage, the LLM, the vector store, the crawler — is an external service you point env vars at.

Infrastructure components

Component	Role
App process	FrankenPHP in Octane mode (recommended) or PHP-FPM behind Nginx. Horizontally scalable behind a load balancer.
Worker process	Horizon (or `queue:work`), handling the `crawl`, `index`, and `default` queues. Separate process group from the app, run under `supervisor`.
Reverb	WebSocket server for realtime widget ↔ dashboard events (live chat, typing indicators). Run under `supervisor` behind a reverse proxy.
MySQL 8 / Postgres 16	Primary database. Daily backups + PITR strongly recommended.
Redis 7	Cache, queue, sessions, conversation history. Persistence on, AOF appropriate.

Environments

Three environments are recommended:

Preview — ephemeral, spun up per pull request. Throwaway data.
Staging — long-lived QA mirror with production-like data shape.
Production — customer-facing, behind CI gating.

Recommended sizing

Starting point for a low-volume launch:

Component	Instances	Per instance
App (FrankenPHP / PHP-FPM)	1–2	2 vCPU / 2 GB
Worker (Horizon / queue:work)	1–2	2 vCPU / 2 GB
Reverb	1	1 vCPU / 512 MB–1 GB
MySQL / Postgres	1	2 vCPU / 4 GB / 50 GB SSD
Redis	1	1 GB

For a single-tenant install, app + worker + Reverb + MySQL + Redis can all co-locate on one 2–4 GB VPS. Split out when conversation volume grows.

Reverb itself is very light: ~50–80 MB RAM and <1 % CPU for a typical site (≤50 concurrent WS connections). The constraint is the type of host, not the size.

Reverb (WebSocket) — required

Reverb is not optional — without it, chat-to-human is broken. Setup is three steps:

Fill the REVERB_* variables in .env (app id, key, secret, host, scheme). See the environment variables reference.
Add a supervisor program running php artisan reverb:start with autostart=true and autorestart=true. This keeps the daemon alive across crashes and reboots.
Add a reverse-proxy location block (in your Nginx / Plesk / Caddy config) that upgrades /app and /apps/ traffic to http://127.0.0.1:8080. This lets visitors connect on wss://your-domain.com/app over the same 443 cert as the rest of the site.

Full step-by-step (with example supervisor and Nginx snippets) is in the INSTALL.md that ships with the package, section 8.

Day-to-day commands you'll use:

sudo supervisorctl status glozr-reverb     # is it running ?
sudo supervisorctl restart glozr-reverb    # after .env changes
sudo tail -f /var/log/glozr-reverb.log     # see what it's doing

Migrations & safety

Migrations follow backwards-compatible patterns:

Add columns nullable first, backfill, then enforce.
Schema changes that aren't backwards-compatible ship as multi-step deploys.
Rollback is instant — the previous build remains warm.
Point-in-time recovery should be tested at least quarterly.

Note. Always run php artisan migrate --force as a build-time step before flipping traffic to a new release. Don't rely on the app process to run migrations on first request — multiple Octane workers will race.

Self-hosting checklist

To run on your own Linux host, you'll need:

A reverse proxy in front of the app — Caddy, Nginx, or Plesk — terminating TLS.
MySQL/Postgres and Redis (managed or co-located on the same host with backups configured).
supervisor running at least two programs: queue:work (or Horizon) and reverb:start. Both autostart=true and autorestart=true.
A reverse-proxy location block forwarding /app + /apps/ to Reverb on its internal port (default 8080).
A scheduler cron line: * * * * * cd /path/to/glozr && php artisan schedule:run.
An observability target — Sentry DSN or an OTLP collector — for production errors and traces.