trongate.cloud: you push, we deploy your Trongate app
trongate.cloud is still a work in progress at the time of writing, 4 October 2026.
You push, we deploy. trongate.cloud hosts Trongate apps on Kubernetes, with HTTPS, a database and room to grow, and nothing to configure.
Simple, stable, and scales with you
You push, we deploy
Connect your GitHub repository, then push. Your app is built and deployed,
live over HTTPS at {slug}.trongate.dev.
Nothing to manage
No servers and no Dockerfile. Each project gets its own MariaDB database. Each team gets its own Kubernetes namespace with network policies, so other tenants cannot reach in.
Scales with you
Pick how much memory your app gets, from 256 MB to 1 GB. CPU is not capped while we watch what real apps use, and a Trongate app’s throughput follows the CPU it gets almost one for one.
Built for Trongate
Tailored for Trongate first. Trongate apps are detected and built without configuration, and BASE_URL
and ENV in config.php are set for you. The app you run locally is the app
that runs here.
Stability matters to Trongate developers; the framework’s own essay on its versioning system explains why. trongate.cloud is built with the same priority: few moving parts, and Trongate measured as Trongate rather than as generic PHP.
A proven platform: we run it ourselves
The trongate.cloud control panel is a Trongate app, and it runs on trongate.cloud, on the same platform as every customer app.
Benchmarks
The benchmarks use a stock Trongate v2 app, built exactly the way customer apps are, measured on the platform on 2026-10-04:
- 2,582 requests a second over HTTPS through the public gateway, at 1 CPU.
- p99 of about 29 ms at 1 CPU.
- No evictions under the heaviest run, with the cluster at 78% CPU.
- Throughput follows CPU, from 1,347 requests a second on half a CPU to 7,765 on three.
For the Trongate team: the session finding
Measuring the platform also turned up one thing in Trongate itself, and the data below supports a lazy session pull request to trongate-framework, pending review.
Stock engine/ignition.php calls session_start() on every request. On a
public host, every bot, health check and first visit writes a session file,
and PHP’s session garbage collection then scans a directory that only grows.
Stock p99 climbed to about 1 s after roughly 100,000 session files, and a
returning visitors run on the same pod right after dropped to 1,089 requests
a second because of the pile-up. The lazy session runs used a fresh pod.
The lazy session fix starts a session only when the visitor already has a
session cookie, or when the request writes to $_SESSION:
| 1 CPU | Stock Trongate | Lazy sessions |
|---|---|---|
| New visitors | 1,378, p99 up to about 1 s | 3,464, p99 26 ms, flat |
| Returning visitors | 1,089, after the pile-up | 2,995 |
12 behaviour checks pass with and without the fix: cookies, flashdata across
a redirect, CSRF, a write after 100 KB of output, and no leaked locks.
Starting the session from header_register_callback instead leaked the
session lock under FrankenPHP, so that version was dropped.
Session stores, with lazy sessions at 1 CPU, returning visitors: 2,995
requests a second with files, 1,542 with Valkey (phpredis, persistent) and
913 with Memcached (extension defaults). On Kubernetes, files live with one
pod and are lost when it is replaced, which logs visitors out; a network store
keeps sessions across redeploys and replicas. Without phpredis’
?persistent=1, Valkey dropped to about 250, a new TCP connection per
request.
Requests a second by CPU, for reference:
| CPU | Raw PHP | Trongate, returning visitors |
|---|---|---|
| 0.5 | 2,098 | 1,347 |
| 1 | 4,520 | 3,031 |
| 2 | 8,710 | 5,935 |
| 3 | 11,446 | 7,765 |
Trongate did 62 to 68% of raw PHP here. The Trongate team’s published benchmark puts it at 89% (13,965 against 15,772), but its tool, hardware and concurrency are not published, so the two are not comparable.
Method: Trongate v2 at
cc968cf with a hello-world
module, built with Railpack 0.40.1 for FrankenPHP with PHP 8.4.26 and OPcache
on, plus a raw PHP file with the same response. wrk with a 5 s warm-up, then
3 runs of 20 s: on the cluster 3 threads and 48 connections from the other
node, locally 2 threads and 32 connections pinned to their own core. “New
visitors” send no cookie, as wrk and ab do by default; “returning
visitors” rotate 1000 session cookies with a Lua script. CPU figures are pod
CPU limits set for the runs. At half a CPU, CFS throttling added a p99 tail
of 55 to 70 ms. Railpack’s Caddyfile logs at DEBUG; INFO gave 23% more
requests a second locally and 7% on the cluster at 0.5 CPU. Reproduce it all
with the benchmark
kit.
Try it
Push a Trongate app to trongate.cloud.
trongate.cloud is an independent project and is not affiliated with or endorsed by the Trongate team.