RunCloud’s monthly update zeroes in on three production pain points: HTTP/3 stability, automatic service recovery, and centralized authentication behind NGINX. It also introduces a Sync Agent control to realign dashboard vs. live agent versions after provider-level restores, plus PHP 8.4.11 support on NGINX. Net effect: fewer ghost timeouts, clearer visibility into what’s actually running on each box, and enterprise-style access control without ditching the single-pane-of-glass that made RunCloud popular.
Below is the practical rundown—focused on what changes day-to-day—across RunCloud Agent v2.14.0+2, v2.13.1+7, and nginx-rc 1.27.1+7 in this cycle.
HTTP/3 gets steadier: goodbye sporadic timeouts
Some users hit edge cases with HTTP/3—QUIC over UDP—manifesting as intermittent timeouts and drops. RunCloud Agent v2.14.0+2 ships a fix that eliminates those hiccups.
What it means: if you already serve over HTTP/3, expect more stable connections and fewer inexplicable drops. If you haven’t flipped the switch yet, remember why it matters: HTTP/3 improves handshake latency (0-RTT/1-RTT), avoids TCP head-of-line blocking for multiplexing, and behaves better on lossy or jittery last-mile links (mobile, Wi-Fi). There’s a dedicated guide for enabling HTTP/3 on containerized core servers.
Tip: watch dashboards/logs during peak hours post-update; if you configured HTTP/2 fallbacks, confirm they no longer kick in on false positives.
New “Sync Agent”: align the dashboard with reality
Under Server Settings → Agent Settings, there’s now a Sync Agent option—handy after provider-level restores (cloud snapshots, image rollbacks) when the agent version on the box and the one shown in the dashboard can drift.
With Sync Agent, you can pull the actual agent version from the server, update the UI to match, and upgrade to the latest when ready. Find it in the server’s Settings tab, right above the Danger Zone.
Why it matters: maintenance decisions (enabling features, applying a hotfix) hinge on the real agent version. This saves tickets, guesswork, and misdiagnosis after restores.
Auto Healing 2.0: more reliable restarts, less log noise
Last month RunCloud introduced Auto Healing, which restarts failed services automatically. With v2.13.1+7, they’ve tightened this up: log-related issues are fixed, and scenarios where some services didn’t restart properly have been addressed. In plain English: your “self-repair” just got more predictable.
What’s covered: NGINX, MariaDB, PHP-FPM, and Redis. If these services crash (or hang), Auto Healing tries to bring them back with no human intervention.
Impact: less downtime from transient failures—especially useful at 03:00 when nobody wants a pager. Note that Auto Healing requires RunCloud Agent v2.13.0+7 (or later) and must be enabled under Server → Settings → Auto Healing Services.
Ops truth: Auto Healing is a safety net, not a root-cause fix. If PHP-FPM keeps restarting, look at load, process limits, memory, locking, or WAF filtering before declaring victory.
NGINX gets SSO-friendly: ngx_http_auth_request_module lands
With nginx-rc 1.27.1+7, RunCloud adds ngx_http_auth_request_module. The name is dry; the capability is big: it lets NGINX delegate authentication to an external service—an auth microservice, an enterprise IdP, a token validation endpoint—before proxying to your app.
What this unlocks:
- Single Sign-On (SSO) and central auth for multiple apps behind NGINX—no duplicating auth logic in each codebase.
- API protection at the reverse proxy: pass only if the external checker returns 200 OK; deny with 401/403 otherwise.
- Enterprise scenarios: validate JWTs, integrate OAuth2/OIDC, consume identity claims for fine-grained access.
Who benefits: SaaS teams with many fronts under one domain, agencies running multi-client sites with corporate logins, and anyone needing centralized access control without bloating app code.
Best practices: build a fast auth check (low latency), safely cache decisions where appropriate, and log both decisions and reasons (for auditing).
PHP 8.4.11 on NGINX (and a note on OpenLiteSpeed)
RunCloud now supports PHP 8.4.11 on NGINX. On OpenLiteSpeed, RunCloud doesn’t manage PHP versioning; when the provider ships the new PHP, it will appear automatically on your servers. If you’re on NGINX, schedule the upgrade from the panel as usual.
Recommended flow: test in staging first (extension compatibility, behavior changes), align CLI and FPM (RunCloud has a guide for updating PHP CLI), and plan a low-traffic window.
New & updated docs worth bookmarking
- Adding Custom HTTP headers (security, caching, CSP control)
- Understanding Brotli Compression & Speed Tests (don’t conflate compression with latency)
- How to Update PHP CLI Version (keep CLI/FPM in sync)
- How To Block “Bad” Bots (updated lists and layered strategies)
And on the blog: deleting huge directories on Linux, fixing ERR_NETWORK_CHANGED in Chrome, flushing DNS cache across OSes, diagnosing WordPress DB connection errors, killing processes in Linux, solving ERR_SSL_PROTOCOL_ERROR, checking OS version via CLI, changing WordPress site URL safely, disk-space checks, fixing Cloudflare HTTP 526, top SMTP servers for marketing email, and reCAPTCHA alternatives.
What a sysadmin should do this week
- Upgrade to Agent v2.14.0+2 and nginx-rc 1.27.1+7; use Sync Agent to align versions after any restores.
- Enable/verify Auto Healing and review logs: what restarted and why? Tune limits if patterns emerge.
- Enable HTTP/3 on containerized core servers per the guide; monitor latencies, 4xx/5xx, and QUIC counters after.
- Explore
auth_request: if you have an IdP (OIDC/OAuth2), consider centralizing auth at NGINX and offloading apps. - Plan your PHP 8.4.11 upgrade: staging → production with rollback ready.
What developers & product teams get out of this
- SSO for backends/APIs:
auth_requestreduces app-level auth duplication, enforces policy at the edge, and simplifies role/claim-based rules. - HTTP/3 + Brotli: together, they improve TTFB and overall experience for SPAs/MPAs with heavy assets.
- Auto Healing: buys time at 3 a.m., but keep telemetry and alerting in place to chase root causes.
A culture note: automate with guardrails
Auto Healing and steadier HTTP/3 make automation tempting. Do it with rails: alert if a service restarts n times in m minutes, capture dumps and pre-restart metrics, track Sync Agent versioning, and avoid letting auto-restarts hide design flaws (leaks, N+1, deadlocks).
The good, the better, and the still-to-improve
Good
- Tangible HTTP/3 fix.
- Sync Agent to close dashboard-vs-host gaps.
- Auto Healing is sturdier and quieter.
auth_requestopens the door to SSO and central authZ.- PHP 8.4.11 ready on NGINX.
Better
- The how-to guides bundled alongside—so features don’t languish unused.
Still to improve
- Expose richer Auto Healing telemetry (counters, reasons, heatmaps) for smarter prioritization.
- A guided SSO wizard for
auth_requestwould lower rollout friction further.
Bottom line
This isn’t a flashy “one big feature” release—it’s the kind that moves your SLA and MTTR. HTTP/3 stability removes a thorn for early adopters; Auto Healing earns more trust as a failsafe; auth_request enables SSO/central auth at the edge; and Sync Agent closes a visibility gap that often leads to bad calls after provider-level restores.
For ops and dev teams, the to-do list is clear: upgrade, turn on Auto Healing, enable HTTP/3 where it fits, prototype SSO with auth_request, and stage the PHP 8.4.11 jump. Not headline-grabbing tasks—just high-ROI ones that save outages and sleep.
FAQs
How do I enable HTTP/3 on containerized core servers without breaking things?
Follow RunCloud’s guide to enable HTTP/3 on containerized core. After flipping it on, monitor latency, 4xx/5xx, and logs for the first hours. If there’s a CDN/WAF upstream, confirm it supports QUIC and doesn’t force downgrade to HTTP/2.
What is Auto Healing and which services are covered?
Auto Healing restarts services when failures are detected. It covers NGINX, MariaDB, PHP-FPM, and Redis. It requires RunCloud Agent v2.13.0+7 or newer and must be enabled under Server → Settings → Auto Healing Services. Treat it as a failsafe—still investigate root causes if you see recurrent restarts.
What does ngx_http_auth_request_module do, and how can I use it for SSO?
It lets NGINX call out to an external auth service to decide if a request is authenticated/authorized before proxying to your app. It’s ideal for SSO and central policy enforcement for APIs. With nginx-rc 1.27.1+7, you can validate JWT/OIDC/OAuth2 via a fast verification endpoint, returning 200 OK for valid access and 401/403 otherwise.
How do I upgrade to PHP 8.4.11, and what about OpenLiteSpeed?
On NGINX, schedule the upgrade from the panel, stage first, verify extensions, and align CLI/FPM (RunCloud provides a PHP CLI update guide). On OpenLiteSpeed, RunCloud doesn’t manage PHP versions; when the provider publishes the new PHP, it will appear automatically on your servers.
