Deploy a static website safely

What it means

A static release is a consistent set of HTML, scripts, styles, search files and configuration. Treating that output as immutable means you identify and verify one complete version, then activate that same version without editing it between verification and publication.

Uploading directly into the active site one file at a time can expose new HTML before its dependencies arrive. Separating preparation from activation gives you a complete candidate to inspect while the existing release stays active. The example uses revision b HTML and script-b.js for that candidate, while preserving script-a.js for a previously opened page.

Try it

Example: begin with Candidate bundle = missing asset, Observed current revision = a and Exact candidate approval present? = no. First change only Candidate bundle to complete: the missing-script failure disappears, but absent approval still causes STOP. Then change approval to yes. Inspect the computed result and why it changed. Select Compare with baseline to show the initial and current outcomes; changing an input clears that comparison.

The baseline result is “STOP: release evidence does not match.” Its explanation is: “HTML needs script-b.js but the fixture does not contain it; exact publish approval absent.” These are independent failures: adding the required asset does not supply publication authority. The separate real release procedure still requires exact source/lock, full output verification, staging and an authorized atomic switch. No publication is performed by this example.

Keep Observed current revision at a throughout the baseline-to-contrast exercise. Target HTML revision b and the expected-current guard a are fixed teaching rules, not additional controls.

Reset restores Candidate bundle to missing asset, Observed current revision to a and Exact candidate approval present? to no. It clears input errors and the baseline comparison and restores the baseline result. It preserves your independent open or closed choices for FAQ answers and About this model.

How it works

The key dependency is HTML → referenced asset → usable page behavior. In the baseline, HTML b names script-b.js, but the supplied bundle contains only script-a.js. Publishing that set could let a browser receive the HTML and then fail to obtain its required script. The fixture detects the missing reference; it does not make the request or observe a browser failure.

A complete candidate resolves that internal dependency, but activation is a separate concern. An atomic switch makes a complete release current as one activation step instead of exposing a partly uploaded set. It does not make the release’s content correct, and it does not replace HTML already held by an open page. That older page may still need script-a.js, which is why the example checks old-asset retention as well as the new dependency.

Two additional gates ask different questions. The current-revision guard checks whether the observed before-state still matches the plan. The approval field asserts permission for this exact candidate. A complete bundle cannot compensate for a changed before-state or absent authority, and selecting yes is not a real authorization token. The model reports every failed gate rather than letting one successful check override another.

Worked example

This is a synthetic fixture, not a captured deployment observation.

The effective bundle contains HTML b and script-a.js, but no script-b.js. The expected-current guard matches a, and the old-page asset is present. Those successful checks do not cancel the two failures: HTML b lacks its required script, and exact approval is absent.

The result is “STOP: release evidence does not match.” This tells you which evidence fails the fixture’s gates, not that a real publisher has attempted and rejected a release.

What changes when the condition changes

Change Candidate bundle to complete and Exact candidate approval present? to yes. Keep Observed current revision at a.

The computed result is: “Fixture gates match; no publication performed.” Its explanation is: “HTML b references available asset b; asset a is retained, the current guard matches and approval is asserted.” The separate real release procedure still requires exact source/lock, full output verification, staging and an authorized atomic switch.

The complete fixture contains both script-b.js for the candidate HTML and script-a.js for an old page. That resolves the dependency failure; changing approval to yes resolves the separate approval gate. Neither change performs a deployment.

Now leave that complete bundle and approval in place, but change Observed current revision to c. The result returns to “STOP: release evidence does not match,” with “current guard changed: expected a, observed c.” Revision c is not inherently defective: it simply differs from the before-state this release plan expects. Inspect the changed state and reassess the plan rather than changing the guard merely to obtain a passing result.

In practice

This sequence describes WebsiteHosting.com’s controlled-release policy, not a rule imposed by HTTP or a deployment vendor. It applies to an authorized static-site environment with separately staged releases and a controlled atomic-switch mechanism. It is not a platform-specific command runbook. If the host, supported tooling, exact paths or required permissions are unknown, STOP and obtain those details before making changes.

Permission to prepare a private build does not include permission to change the active site, production release directories, server configuration, DNS or access controls. Do not update the live web root file by file or delete retained releases to bypass the release process.

1. Read-only preflight: establish the exact scope and before-state. Inspect the accepted source revision, dependency lockfile, build identity, output manifest, intended staging and publication paths, current active release and compatible previous release. Confirm the actual environment, tool versions, permissions and available resources without changing them. Record the expected current revision and the approved files and destinations. The expected observation is a consistent, identified starting state. STOP on a mismatch, missing authority or unknown operation outcome; inspect the state before retrying anything.

1. Build and verify privately. Within the authorized work area, build the exact accepted source using its fixed dependency lock, as an unprivileged user without production secrets. Identify the complete output and preserve the manifest and checksum evidence that bind it to the candidate. Verify routes, asset references, search and affected interactions. Expected results include the intended version marker, working expected pages and assets, and the intended 404 response for a nonexistent route. A build exit status alone is not this evidence. STOP if output identity or behavior differs from the plan.

1. Prepare recovery before publication. Preserve the compatible previous release and the assets needed by older pages. Define the authorized rollback target, switching scope and verification criteria. Any private release/rollback rehearsal under this project policy must use a new isolated sandbox, not production paths. Observe that the sandbox can return to the expected previous version and behavior; do not record an unperformed recovery test as successful.

1. Accept the source, then separately authorize inactive staging. Stage only the identified complete candidate at the approved inactive destination. Preview that exact staged output and repeat the relevant route, asset, search, version and interaction checks. Confirm that staging has not changed the active release. If the staged identity differs from the verified candidate, STOP; the earlier evidence no longer establishes what would be published.

1. Authorize and activate the exact release. After staged evidence is available, obtain explicit publication approval for the specific release/build identity. Recheck the active-release guard immediately before the authorized switch. If it has changed, STOP and reassess the before-state. Only the trusted publisher performs the atomic activation. If the existing publisher cannot handle the intended release, its modification requires a separate, narrowly authorized operation with its own backup and rollback plan.

1. Verify public behavior and recover within authority if needed. After activation, check public HTTPS responses for expected pages and an intended 404, the version marker, search, required assets and affected interactions. Confirm the observed active identity, not just the publisher’s success message. If checks fail, STOP further changes and use the explicitly authorized rollback plan to restore the compatible previous release. Verify its active identity and expected public behavior afterward. If the switch outcome is unknown, first determine what is active rather than blindly repeating publication or rollback.

Limits and unknowns

This scene uses synthetic HTML and asset revision keys. It does not build a site, calculate hashes, inspect a manifest, verify credentials or approval, request an asset, test staging, switch a release or exercise rollback. A matching fixture therefore establishes only that its declared local gates match—not that a real deployment is ready.

The offered bundle choices expose different failures. The mixed HTML fixture contains HTML a and only asset b: the HTML is not the intended revision b, its script-a.js dependency is missing, and the old-page asset is not retained. Those failures remain STOP conditions even if approval is set to yes.

The fixture has no control for missing real-world evidence. If actual source identity, authorization, current state or an operation’s outcome is unknown, readiness remains unestablished: STOP and collect the missing evidence. If the shared controls report invalid input, no calculated outcome applies until you correct it or use Reset.

Without JavaScript, the initial result and worked contrast remain readable, but the controls do not operate. The example makes no external request and cannot report that your site has been deployed or repaired.

What to carry forward

Treat publication as activation of one identified, verified release—not as completion of an upload. Before switching, you need evidence for the candidate, the unchanged before-state, exact authority and a recovery path. After switching, verify what the public site actually serves; a successful build or activation alone cannot establish that.