Render Gave Every Service a Deploys Page: The Minimum Deploy Visibility Your Self-Hosted Dashboard Owes You

The 2 a.m. question Render just answered properly​

Every operator knows the question: what is actually live right now? Not what the last merge to main was, not what the CI pipeline claims it shipped — what code is serving production traffic at this exact moment, when it went out, and what it replaced. At 2 a.m., with an error budget on fire, that answer needs to be one glance away, not an excavation.

Until this month, Render's own answer to that question was surprisingly weak for a managed PaaS. Deploys were visible only on the Events page, interspersed with every other service event, and capped at a 90-day history. Anything older than three months simply aged out of view. On September 3, 2026, Render fixed it with a changelog entry titled See your service's deploys on a new page: every service now gets a dedicated Deploys page with uncapped history, a Live badge on the current deploy, in-progress rollout status, and a banner when auto-deploys are disabled. Cron jobs got the same treatment with separate Builds and Runs pages.

The interesting part is not that Render shipped a nicer page. It is what the change admits: deploy history is not an event stream. It is a permanent, first-class surface — an audit trail and a rollback index, not a log tail that expires. If you run a self-hosted fleet, that admission sets the bar your own tenant dashboard has to clear. Here is the minimum spec, scored against what the self-hosted alternatives give you today.

The minimum spec: five things your dashboard must show​

Before looking at any vendor's implementation, here is the checklist. A deploy-visibility surface that cannot do all five of these will, sooner or later, send an operator digging through CLI output during an incident — which is exactly the failure mode Render just designed away.

1. Full deploy history with no date cutoff. Every deploy the service ever had, newest first, with its commit, timestamp, and outcome. The moment history expires — 90 days, 10 revisions, whatever the limit — the deploy you need to compare against is always the one that aged out. Retention limits on deploy history are a bet that you will never investigate anything old, and incidents do not respect that bet.

2. An explicit live pointer. A badge, a highlight, a pinned row — something that says this deploy is serving traffic right now, distinct from the most recently finished deploy. The two diverge more often than people admit: a deploy can succeed while traffic still drains to the old version, a rollback can leave the newest row pointing at a deploy that is no longer live, and a failed deploy leaves the previous one live with nothing in the list saying so.

3. In-progress rollout status. When a deploy is mid-rollout, the dashboard must show that state — building, deploying, awaiting health checks — rather than showing the previous deploy as Live with no hint that a replacement is halfway out the door. The most confusing minute in operations is the one where the dashboard says everything is fine because it only renders settled states.

4. A build/run split for scheduled workloads. Cron jobs have two histories tangled together: the code that was built and the executions that ran. Render's new Builds and Runs pages separate them, and the reason generalizes: when a scheduled job fails, "which build ran" and "which runs failed" are different questions with different answers, and a single interleaved list makes both harder.

5. Auto-deploy state, surfaced. A banner saying auto-deploys are disabled seems like a footnote until you watch someone merge a fix, wait ten minutes, and conclude the fix did not work — when in fact nothing deployed at all. Whether pushes flow to production automatically is load-bearing context for reading every other row on the page.

Omit any one of these and you recreate the archaeology problem in miniature: the operator can see something, but the specific thing they need is one CLI command, one API call, or one guess away.

What Render's Deploys page actually shows​

Render's September 3 change maps onto that checklist almost item for item, which is why it works as a reference implementation rather than just a product note.

The Deploys page shows the service's deploy history without a date cutoff — the direct fix for the old 90-day Events-page cap. Each deploy carries its status, so in-progress deploys read as in-progress instead of vanishing into the gap between "previous Live" and "new finished." The Live badge marks the current deploy explicitly, decoupling "what is live" from "what finished most recently." And the banner flagging disabled auto-deploys puts item five where nobody can miss it: at the top of the page whose rows it recontextualizes.

Two details are worth noting for what they chose not to change. First, the Events page continues to show all service events, including deploys. Render did not move deploy history; it duplicated the lens — the stream stays a stream, and deploys additionally get a permanent surface. That is the right call: streams and histories answer different questions, and collapsing them was the original sin. Second, cron jobs got separate Builds and Runs pages, acknowledging that scheduled workloads need the build/run split from item four as dedicated surfaces, not filters on one list.

None of this is exotic technology. That is the point. The spec is five unglamorous behaviors, and until this month one of the most polished managed PaaSes in the business failed most of them. Which raises the question: how do the self-hosted options score?

How the self-hosted alternatives score against the spec​

Score each tool against the five checklist items — full history, live pointer, rollout status, build/run split, auto-deploy state — and a pattern emerges: every self-hosted option nails a different subset, and raw Kubernetes nails almost none of it.

A few notes on the rows that need unpacking.

kubectl rollout history is the archaeology this post warns about. It shows numbered revisions, not commits: no SHA, no image digest, no actor, no timestamp you can trust at a glance. The default revisionHistoryLimit of 10 means the eleventh deploy back is gone, and the CHANGE-CAUSE column that once carried human context relied on kubectl --record, long deprecated and gone. Answering "what is live" from this surface means correlating a revision number with ReplicaSets, then with pod image digests, then with your CI system — three hops, all manual, all during an incident.

ArgoCD gets history and rollback right but the live pointer only halfway. Its per-application revision history and one-click rollback are the closest Kubernetes-native equivalent to Render's page. The caveat is philosophical: ArgoCD's source of truth is Git, so a UI rollback reapplies old manifests without changing Git — and ArgoCD disables auto-sync when you do it, because the cluster and the repo have now diverged. That is correct GitOps behavior, but it means "what is live" and "what Git says should be live" are two different answers, and the dashboard's job is to show both without conflating them.

Coolify is the most complete self-hosted answer. Independent comparisons consistently credit it with the more mature container lifecycle: deployment history, rollback support, and detailed logs, against Dokploy's more basic start/stop/restart/logs coverage. If you self-host on a single box today, Coolify is the closest you get to the five-item spec out of the box — which matters because it proves the spec is achievable without managed-PaaS resources.

The gap between Coolify-on-one-box and a fleet dashboard is the actual work: none of these tools, except Render's new page, hands a tenant — someone who does not have kubectl, does not know what a ReplicaSet is, and should not need to — a single surface answering all five questions.

History you can act on vs. history you can only read​

There is a deeper reason permanence matters, beyond incident archaeology: deploy history you can act on is a rollback index and an audit trail, while history you can only read is a souvenir.

Render's history is actionable because each entry is a rollback target. The rollback API takes a deployId and re-runs a previous deploy's image and configuration — the dashboard row and the recovery action are the same object. Compare that with a 90-day event stream, where the entry for the last known-good deploy can expire before you need it.

The failure mode is specific and nasty: a slow-burning regression ships, nobody notices for three months, and when someone finally bisects it, the deploy that introduced it has aged out of the only surface that recorded it. The git history still exists, of course — but the mapping from "this commit" to "this production deploy with this config and this outcome" lived in the expired stream.

The same logic applies to audit. "Who shipped what, when" is a compliance question as often as a debugging one, and a capped history answers it only for the recent past. Uncapped history turns the Deploys page into evidence, not just information.

For a Kubernetes-based fleet, the uncomfortable corollary is that Deployment revisions are not a deploy history. They lack the fields that make history actionable: no commit SHA, no image digest, no actor, no build logs, no recorded outcome beyond "this ReplicaSet exists." Building the five-item spec on a Cluster API fleet means keeping real deploy records — in a database or in CRDs — with at least commit SHA, image digest, actor, timestamps, and status, and deriving the Live pointer and rollout status from observed state rather than from whichever Revision happens to be newest. That is genuine engineering work, not a UI skin over rollout history. But Render just demonstrated that the managed competition considers it table stakes.

Conclusion: deploy visibility is API surface​

One more thing worth noticing about the timing. Render shipped the Deploys page in the same season it has been pushing hard on machine-readable surfaces: a versioned CLI, Python and TypeScript SDKs, an MCP server, and an agents page for deploying with coding agents. Dashboard visibility and agent visibility are converging — the "what is live right now" question will increasingly be asked by an agent triaging an incident, not just a human staring at a page. A deploy history that only exists as pixels helps the human; a deploy history backed by records with IDs, like Render's deployId, helps both.

That is the standard to hold any self-hosted dashboard to, whether the reader is a person or a model: full history, live pointer, rollout status, build/run split, auto-deploy state — each backed by queryable records, not just rendered rows. Render needed until September 2026 to give its own tenants that surface. Your fleet's tenants should not have to wait longer.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.