# Dashboard hosting Source: https://www.fortrabbit.com/use-cases/dashboard-hosting Created: 2026-07-22 Reviewed: 2026-07-27 > Host a PHP dashboard app — analytics panels and data visualizations — with the heavy aggregation precomputed in the jobs component so the charts load fast. **Ten people watching. Fifty million rows behind them.** A PHP application whose whole job is to show numbers: an analytics panel, a reporting tool, a metrics wall on an office screen. The charts are the visible part, and the cheap part. The work sits behind them, in the queries that turn raw rows into the figure on display. ## The aggregation runs before the request The slow query is the one that reads a whole table to produce a single average. Running it on every page load ties the dashboard's speed to the size of the data, which only moves one way. Cron jobs in the jobs component do that reading on a schedule and write the results into summary tables. The panel reads a small, ready-made row instead, and the expensive part already happened where nobody was waiting. A rollup over a year of events can take minutes in a worker without a browser tab spinning. ## "Real time" is a poll, not a push Persistent connections aren't available here, and it's worth being plain about it: nothing on the platform pushes an update to a panel that's already open. WebSockets and live-streaming charts are out. What works is polling — the panel asks again every few seconds — or a refresh on the precomputed data as each rollup lands. For a dashboard that trails reality by design, the difference is hard to see. ## The data outgrows the traffic Ten people might watch a dashboard that sits on tens of millions of rows. Counted by visitors it looks idle; counted by the database it's the opposite. Load-based reasoning gives the wrong answer, the same as it does for an [internal tool](/use-cases/internal-tool-hosting). Components are booked one at a time, so MySQL grows on its own — more storage and memory for the data — while the PHP component stays small, each billed pro-rated by the day. ## Why fortrabbit? A dashboard's cost sits in the database, not the page, and the components here are built to grow apart. MySQL is managed as a first-class part of the platform, not bolted on beside it — PHP and MySQL have been the main event at fortrabbit from the start. Precompute in the jobs component, scale the database for the data while PHP stays small, and pay per day for exactly what each component uses. The numbers are ready before anyone thinks to ask for them. ## FAQ ### Can the panels update in real time? **Near real time, by polling** — Persistent connections are not available on the platform, so nothing pushes an update to a panel that is already open — anything built on WebSockets is out. Panels refresh by polling on an interval, or by reloading the precomputed data as each rollup lands. For a metrics view, a few seconds of lag reads as live. ### Where should the heavy aggregation run? **In the jobs component** — Rolling up millions of rows on every page load ties the dashboard's speed to the size of the data. Cron jobs in the jobs component do that reading on a schedule and write the results into summary tables. The panel then reads a small, ready-made row, and the expensive query already ran where nobody was waiting. ### What happens when the dataset outgrows the traffic? **Scale MySQL on its own** — A dashboard's data usually grows faster than the number of people watching it. The database component is booked and scaled independently of PHP and billed pro-rated by the day, so storage and memory grow without paying for web capacity that stays idle. ### Does the charting need a special runtime? **No** — Charts render client-side with the usual libraries — Chart.js, ECharts, ApexCharts — or as server-side SVG from PHP. It is an ordinary PHP application deployed with git push; nothing on the platform is specific to visualization. ### Can it read from other systems? **Yes** — Outbound calls to a data warehouse, an analytics API, or another database work. Each environment has a fixed outgoing IP the other side can allowlist, and non-standard ports open per environment from the fortrabbit dashboard. Scheduled imports run in the jobs component. --- - [Jobs and workers](/features/jobs) - [MySQL](/features/mysql) - [Agent ready](/workflows/agentic-engineering)