# Internal tool hosting Source: https://www.fortrabbit.com/use-cases/internal-tool-hosting Created: 2026-07-20 Reviewed: 2026-07-27 > Host the internal PHP application only staff uses — admin panels, intranets, stock and reporting tools. Low traffic, high consequence, long service life. **The least glamorous PHP in the building, and the most load-bearing.** The application only a company's own staff uses: an admin panel, an intranet, a stock or logistics tool. PHP holds an enormous share of these, written quickly, years ago, by whoever was available. ## Low traffic, high consequence 20 concurrent users at peak, nothing on weekends. By every metric a hosting dashboard reports, the application looks idle. When it stops, invoices aren't raised and shipments aren't booked, and the manual fallback was forgotten years ago. Load-based reasoning gives the wrong answer here. The PHP component and the database run through the working day whether anyone logs in or not, and that, plus backups, is the bill. ## Wired into the other systems An internal tool is rarely alone. It reads orders from the ERP, posts labels to the warehouse, mails a report before the shift starts. Each environment has one fixed outgoing IP, so the firewall on the other side has a single address to allowlist. Non-standard ports open per environment from the dashboard, and scheduled imports and exports run as cron jobs in the jobs component. Persistent connections and WebSockets are not supported. ## Old code, current runtime Age in the application is fine. A CakePHP or CodeIgniter code base nobody has touched in years deploys like any other — git push, Composer, done. Age in the runtime is the limit: the platform starts at PHP 8.2, and an application pinned below that needs work first. That work happens in a second environment. Same code, newer PHP, proven there before anyone in the company sees it. ## Why fortrabbit? Because boring is the entire specification, and boring on purpose is what fortrabbit has been doing for over a decade — managed PHP, bootstrapped, still run by the people who built it. A current runtime nobody in-house has to patch, daily backups behind data that exists nowhere else, and support answered by the operators of the platform rather than a ticket desk. That last one matters more than it should, because the developer who wrote the tool usually left years ago. ## FAQ ### Can access be restricted to the office network? **Coarsely, yes** — There is no VPN or private networking — an internal tool is reachable over the public internet like any other app. Two coarse gates exist: the password protection setting puts HTTP basic auth in front of the whole environment, and .htaccess rules can limit access to known office IPs. Both apply to the environment as a whole; anything per-user runs through the application's own login. ### Does an older code base still deploy? **Usually yes** — Age in the application is fine; age in the runtime is not. A CodeIgniter or CakePHP code base from years back runs happily as long as it works on PHP 8.2 or newer — that is where the platform's version range starts. Applications pinned to an end-of-life PHP release are not a good fit. ### Is a low-traffic app cheaper to run? **Somewhat** — Traffic is rarely the cost driver here. What is paid for is existence — a PHP component and a database that must be available during working hours regardless of how few requests arrive. Components are booked individually and billed pro-rated by the day. ### Can the tool talk to other internal systems? **Yes** — Outbound calls to an ERP, a warehouse API or a mail server work; non-standard ports are closed by default and get opened per environment in the dashboard. Each environment has a fixed outgoing IP the other system's firewall can allowlist. The jobs component runs the scheduled imports and exports. Persistent connections and WebSockets are not supported. ### How important are backups for an internal tool? **Very** — More than for a public site, because the data is often unique to the company and exists nowhere else. The backups component keeps restorable snapshots, which matters most for applications whose original developer has long since moved on. --- - [Backups](/features/backups) - [Developer support](/benefits/get-support) - [Agent ready](/workflows/agentic-engineering)