# Integration middleware hosting

Source: https://www.fortrabbit.com/use-cases/integration-middleware
Created: 2026-07-20
Reviewed: 2026-07-20

> Host PHP integration middleware on fortrabbit — webhook receivers, scheduled importers, sync jobs between a shop and an ERP. Workers and crons in one jobs component.


A small PHP service with no user interface, sitting between other systems. A webhook receiver, a sync between a shop and an ERP, a scheduled importer. Nobody visits it; it exists to move data, and PHP is a reasonable choice precisely because a library for every API it will touch already exists.

## The jobs component is the center of gravity

Two things trigger this service: an inbound webhook and the clock. The jobs component covers both — long-running workers and cron jobs — running in a separate container that shares the codebase, database, and environment variables with the web processes. Each deploy restarts running workers, so background code never lags behind the web code.

The web side exists to catch a payload and hand it off. A middleware app where the web request does the heavy lifting has the proportions backwards, and it shows up as timeouts during the first upstream burst. The queue backend here is MySQL — the database queue drivers in Laravel and Symfony run against the booked component; there's no hosted broker product.

## Failure is silent

Nobody complains when an integration stops, because nobody was watching it. The dashboard keeps a dedicated jobs log next to the web logs, but alerting on absence is something the team arranges elsewhere.

Cost is close to nothing. There's no traffic to speak of and the database stays small, so the bill is one PHP component and the jobs component, aggregated per day of actual use.

## FAQ

### Does middleware need a web front end at all?

**Barely** — Enough to receive webhooks and nothing more. There are usually no templates, no sessions and no login screen. A handful of routes accept posted payloads, verify a signature or a shared secret, and hand off to a worker.

### Is there a managed message queue?

**No** — There is no hosted broker product. The pragmatic queue backend is the MySQL component — the database queue drivers in Laravel and Symfony run against it without extra configuration, and it handles the volumes typical middleware sees. The jobs component runs the workers that consume it.

### How are scheduled imports run?

**Cron in Jobs** — The jobs component covers both cron schedules and long-running workers, configured per job in the dashboard with a crontab-style interval and a max runtime. A nightly importer and a queue consumer live in the same app, sharing its code base and environment variables.

### Will the platform alert when the integration stops running?

**No** — There is no alerting product here. The dashboard keeps a dedicated jobs log next to the web logs, so what a worker printed last is always one click away. Alerting on silence — a heartbeat that stops arriving — is arranged with an external service. Middleware fails quietly, so this is worth setting up early.

### What does middleware cost to run?

**Very little** — Traffic is negligible and the database stays small. Cost concentrates in one PHP process and the jobs component, booked individually and billed post-paid per day of use, at 1/30th of the monthly price.

---

- [Jobs and workers](/features/jobs)
- [Dev tips](/dev)
- [Agent ready](/platform/ai-ready)