How EONAPP Makes a Static PWA Release Reproducible

A commit hash is necessary, but it is not the whole release

A static web application can still have a surprisingly complex release chain. Source is committed, dependencies are installed, assets are built, service-worker files are stamped, Functions are bundled, database migrations may be applied and a hosting platform creates a deployment with its own identifier. If the team records only “we deployed commit X,” it can be difficult to prove later that the bytes serving on the custom domain were actually built from that source under the intended release process.

EONAPP addresses that by carrying three source/build identities through the release: the Git commit, the Git tree and an immutable candidate digest produced by the protected build. The commit identifies history, the tree identifies the exact repository content and the candidate digest identifies the generated release candidate. A successful release must preserve the relationship among all three.

Protected Preview is a certification stage

Before Production, the candidate runs through a Protected Preview workflow. The workflow validates source contracts, builds the candidate and publishes a Preview deployment that can be tested without moving the canonical domain. The Preview run ID becomes part of the later Production authority. This is important because “Preview looked fine” is otherwise a vague statement; a run ID ties the observation to a concrete source and build.

Production does not accept an arbitrary latest build. The protected release rechecks the source authority and rebuilds or verifies the candidate against the expected digest. If the tree or candidate differs, the release should stop instead of assuming the change is harmless.

One-use authorization separates preparation from cutover

EONAPP uses a short-lived, one-use authorization record for the controlled Production path. The authorization contains the repository identity, source commit, source tree, candidate digest, Preview run and an expiry. It also records that paid traffic must remain off. The release consumes the authorization before completing the mutation, so a stale approval cannot simply be replayed for a later build.

This mechanism is intentionally more cumbersome than clicking “Deploy.” Production cutover is the step where mistakes become public, so the workflow asks for stronger evidence than ordinary development. The authorization is not a replacement for tests; it is a boundary that says which already-tested candidate is allowed to cross into Production.

Rollback authority is captured before the cutover

A release is safer when rollback is a prepared operation rather than an improvised response. Before moving the canonical domain, EONAPP records the currently successful Pages deployment and the database recovery prerequisites. If a P0 condition appears—wrong provenance, broken authentication, a migration mismatch, a secret leak or a widespread runtime failure—the workflow can return to the captured deployment rather than searching deployment history under pressure.

Database state requires its own attention. A static asset rollback cannot undo an incompatible schema mutation. That is why D1 migration authority and Time Travel or backup receipts are treated as part of the release evidence rather than a separate afterthought.

The direct deployment URL matters

During the September 2026 launch work, direct Pages deployment URLs were useful for separating candidate runtime behavior from the canonical alias. A new candidate could exist and be tested while eonapp.ch still pointed at the previously successful deployment. This made it possible to prove missing runtime bindings and Push readiness without confusing “the candidate is unhealthy” with “the custom domain has not cut over yet.”

The safe order is conceptually simple: deploy the exact candidate, test the candidate deployment, complete the intended Production cutover, then verify the canonical domain and provenance again. A workflow should never create a circular requirement where the custom domain must already serve the new candidate before the cutover step is allowed to happen.

PWA service workers add another source of stale state

A normal webpage refresh fetches current assets relatively directly. A PWA can have a service worker controlling navigation and cached resources. That means a release can be correct on the origin while an installed client still sees older assets. EONAPP treats service-worker versioning and the update path as release concerns. After deployment we verify the manifest, service worker, reload/update behavior and whether stale UI survives unexpectedly.

This is also why the release evidence includes browser checks rather than only HTTP status codes. A page that returns 200 can still be functionally old if the client remains under an earlier service worker.

A minimal reproducible evidence chain

Why this is useful even for a small project

Reproducible release evidence is often associated with large teams, but a solo project benefits even more because the same person is writing code, configuring providers, editing Cloudflare and testing the browser. The evidence chain reduces cognitive load. Instead of remembering which of several late-night deployments is live, the operator can compare the canonical provenance with the certified candidate.

The goal is not ceremony for its own sake. The process should make failures cheaper: wrong build, stop before cutover; missing binding, rollback automatically; stale service worker, fix the update path; migration mismatch, use the recorded database recovery authority. A release system earns its complexity when it turns a potentially ambiguous Production incident into a bounded diagnosis.