---
title: "1.15.4 — The Deploys tab loads; Edge can serve HTTPS-only"
description: "A patch release with one fix that matters more than its size: the app Deploys tab read releases and deploy history from two URLs that do not exist, so it had never loaded since it shipped — the panel simply stayed empty. 1.15.3 made that visible by rendering an error instead of nothing; this release…"
date: "2026-08-20"
tags: ["release"]
canonical: "https://django-mojo.sitesmojo.com/changelog/1-15-4/"
---

A patch release with one fix that matters more than its size: the app Deploys tab read releases and deploy history from two URLs that do not exist, so it had never loaded since it shipped — the panel simply stayed empty. 1.15.3 made that visible by rendering an error instead of nothing; this release makes it work. Edge gains a deployment-level listener posture: a DNS-01-only fleet can now render HTTPS-only vhosts instead of always emitting a port-80 block, and the portal's Vhosts page reports the responding node's posture as read-only evidence.

### Added

- `EDGE_HTTP_ENABLED` — file-only, boolean, default `True`. Set it false on a DNSMAN / DNS-01-only fleet to render HTTPS-only vhosts. It governs nginx generation only, not load-balancer listeners or firewall ingress, and when false `EDGE_ACME_WEBROOT` is not read.
- The portal's Vhosts page reports the responding node's certificate serving posture — whether its generated public HTTP vhosts are enabled, and that DNSMAN issuance uses DNS-01. Read-only operator evidence, not a toggle and not a proof of fleet convergence.

### Changed

- A vhost is now one HTTPS server block plus an *optional*, deployment-controlled HTTP shell, rather than an unconditional 443 + 80 pair. The posture is a deployment-level choice, not a per-vhost one, and is not writable through the vhost API.
- Edge posture convergence and reporting hardened.

### Fixed

- The app **Deploys** tab never loaded. It read releases and deploy history from `/api/edge/webapp/release` and `/api/edge/webapp/deployment`; both resources are registered top-level, so both requests 404'd and the panel stayed empty. Reported as "clicking Deploys does nothing", which is what a rejected fetch looks like when nothing renders an error.

### Upgrade notes

- `EDGE_HTTP_ENABLED` defaults to `True`, so rendering is unchanged unless you set it false. Do not set it false on a fleet that still relies on HTTP-01 issuance or on HTTP→HTTPS redirects served by nginx.
- Port-80 exposure at the load balancer or firewall is managed separately and is unaffected by this setting. Turning off HTTP rendering does not close the port.
- The admin bootstrap payload gained an `edge` block (`available`, `http_enabled`, `dnsman_issuance`). During a mixed-version rollout, or on an installation without Edge, these read as unknown rather than defaulting to healthy.
- Every REST path the admin portal calls under `/api/edge/` is now checked against the registered routes by an asset contract test, so a mistyped endpoint fails a test run instead of surfacing as a blank panel. The equivalent audit for `/api/account/` paths is not yet in place.