An additive deploy is an additive disclosure

An additive deployment feels conservative. Copy the new build over the old one. Replace files that changed. Leave everything else alone. Nothing is deleted, rollback seems easier, and the operator avoids the frightening command that makes destination and source exactly match. For a public site, however, this apparent caution has a hidden meaning: anything ever copied may remain publicly retrievable after the system that produced it has forgotten it exists.

That residue is not merely clutter. A retired draft can remain indexed. A renamed page can create two conflicting versions. A build note can sit beside the page it helped generate. A source map, manifest, backup, or internal explanation can become reachable by anyone who knows or guesses the path. The current build may be clean while the public directory continues to disclose the history of every earlier mistake.

The operational error is confusing non-deletion with non-destruction. Leaving files behind preserves bytes, but it can destroy the boundary between public and private. It also destroys confidence that the release being inspected is the release being served. The directory becomes a sedimentary record whose deepest layers are still online.

The destination is part of the release

A release is not only the files that a build produced. It is the complete set of files a server is willing to return after deployment. If the deployment process does not control that set, the build manifest is incomplete. A reviewer can approve every intended artifact and still miss an old file left at a stable URL.

This is why packaging should begin with an allowlist. The release process should name the file classes that belong in public: rendered pages, declared assets, machine-readable discovery files, and any other intentional resources. Authored source, operational notes, backups, credentials, temporary files, and build scripts stay outside unless a specific rule admits them. The NIST Secure Software Development Framework treats secure development as a set of practices across the lifecycle; release packaging is one of the places where that discipline becomes concrete.

A denylist asks whether anyone remembered every dangerous suffix and filename. An allowlist asks a more stable question: what does this product actually need to serve? New internal file types remain excluded by default. That makes packaging fail closed when the source tree evolves.

A public directory should contain what the release permits, not everything the copy command happened to encounter.

The allowlist must be applied to an empty staging destination. Otherwise an excellent package can still be overlaid onto yesterday’s residue. Build the next release in a fresh directory, validate it there, and then switch the server to that complete artifact. The old release can be retained outside the public path for rollback. Public replacement and operational preservation are compatible when they occur in different places.

Absence is a property to test

Deployment tests usually prove presence: the homepage returns success, the stylesheet loads, and a sample article renders. Security also depends on absence. Internal extensions should not be served. Source directories should not exist at public paths. A page removed from the release should return the intended status. The test suite should carry representative forbidden paths and verify them after every deployment.

HTTP makes these observations precise. RFC 9110 defines the semantics clients use to interpret success and error responses. A release validator can use those semantics to distinguish a resource that is intentionally available from one that is absent, redirected, or unexpectedly exposed. The point is not to worship status codes; it is to make the public boundary observable.

Inventory comparison adds another control. Count the staged files by class. Compare the staged paths with the build manifest. Compare the live paths with the staged paths after the switch. Large sites need efficient tools, but the principle remains simple: every served file should have an explanation in the current release.

This approach improves rollback as well. An atomic release directory is a coherent version. Returning to the prior version means switching back to another coherent directory, not trying to infer which overwritten and leftover files represent the previous state. Rollback stops being archaeology.

Additive deployment is tempting because deletion feels irreversible. On a public boundary, the more serious irreversible act may be disclosure. Once a private file has been served, replacing it cannot make every recipient forget it. Release engineering should therefore be conservative about exposure, not conservative about stale files.

Caching makes the stakes larger. A file removed from the origin may persist in a content-delivery network, search cache, browser cache, or external archive. Response headers can govern some reuse, but they cannot guarantee recall after disclosure. Prevention belongs at packaging time, before the first successful response. Cleanup remains necessary, yet it should be described honestly as containment rather than reversal.

The same discipline applies to redirects. A stale page should not be redirected blindly to the homepage merely to avoid an error count. Redirect it only when a genuine successor exists; otherwise return an accurate absence. A coherent destination is easier to defend than a site that keeps every old path alive through increasingly misleading substitutions.

The governing question is not “what did we copy?” It is “what can the world retrieve now?” Build that answer from an allowlist, stage it cleanly, replace the destination coherently, and verify both presence and absence. Repeat the inventory after the switch. A deployment becomes trustworthy when the public surface is exactly the artifact the institution intended to release.

— Dispatches · Summit Cognitive