Jonas Hansen

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:

ignition.lazy.php
if (isset($_COOKIE[session_name()])) {
    session_start();
} else {
    $_SESSION = [];
    ob_start();
    register_shutdown_function(function (): void {
        if (empty($_SESSION) || session_status() === PHP_SESSION_ACTIVE) return;
        if (headers_sent()) return; // logged in the real patch
        $data = $_SESSION;
        session_start();
        $_SESSION = array_merge($_SESSION, $data);
    });
}
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.