01 · The absurdity

The Governed Static Publishing Lane

A qualifying static site should inherit an approved publishing system rather than implement its own delivery pipeline.

The deliverable is a directory of HTML, CSS, JavaScript, images, and approved downloads. The process often arrives dressed as a transactional application: container images, bespoke pipelines, manual credentials, security tickets, infrastructure handoffs, and evidence rebuilt from scratch.

Security checks are legitimate. Rebuilding the same mechanics, controls, credentials, and proof in every repository is not. A bad process written in YAML remains a bad process, merely with better indentation.

Classify a workload Download the implementation kit

02 · The actual problem

Six decisions were welded into one opaque process.

Hosting

Where immutable files are served.

CI orchestration

What invokes the reusable contract.

Security controls

Which checks apply to this risk tier.

Release approval

Who authorizes an environment transition.

Evidence

What proves the artifact and checks.

Ownership

Who supports, reviews, and retires it.

The governing principle: encode the applicable controls once, publish them as a versioned product, and let repositories declare intent through a thin adapter.

03 · Choose your view

View this recommendation as

Each view changes the nearby summary, proof signals, objections, and actions. Your explicit choice persists on this device.

Engineering view selected

Provide a deterministic artifact root, not a new platform.

Commit the source, declare the output directory, keep secrets and server behavior out, run the same checks locally, and receive an immutable preview plus receipt.

Provide: HTML, CSS, JS, images, approved downloads
Frameworks: Plain files or deterministic React, Astro, Vue, and equivalents
Failure: Fail closed with a named check and local reproduction
Rollback: Redeploy a previously receipted checksum

Recommended actions

Declare outputPath and runtime.
Run the qualification command locally.
Keep environment-specific content out of built bytes.

Objection answered: “Every site is unique” does not mean every site needs unique delivery mechanics.

04 · Classify the workload

A deterministic educational decision aid

This guide identifies a likely lane. It is not an authoritative corporate approval engine and cannot replace local architecture, security, privacy, legal, or records review.

Current deterministic result

Static content lane

Recommended hosting

Purpose-built static hosting; evaluate authentication and network posture separately.

Minimum controls

Secrets and content checks
HTML, links, accessibility, and headers
Ownership, checksum, and receipt

Disqualifying conditions

Any server runtime, state mutation, user-submitted data, or runtime secret moves the workload to S2.

Unresolved local review

Confirm content classification, audience, identity, network, records, and release requirements.

Read the classifier rules without JavaScript

If server code, state mutation, user-submitted data, background work, sensitive processing, or runtime secrets exist, classify S2 and exit this lane.
Otherwise, if client-side logic or approved API calls exist, classify S1 and add dependency, SBOM, CSP, endpoint, and browser-security controls.
Otherwise classify S0 and apply the baseline static-content controls.
Controlled content and private-network requirements do not change S0/S1/S2 by themselves; they add unresolved local authorization, hosting, and network decisions.

05 · Current versus target

Move the system boundary

Current state selected

Every repository rebuilds the delivery system.

Control intent may be legitimate, but implementations, credentials, evidence, approvals, and failures fragment across repositories.

Current: repeated application-scale delivery

Repository ABespoke Jenkinsfile
Repository BDifferent YAML and credentials
Repository CContainer added for static files
Security reviewEvidence reassembled repeatedly
Manual releasePortal action and unclear rollback

Failure signature: the organization standardizes tools while preserving implementation variance.

06 · The pipeline contract

The repository declares intent. The platform supplies mechanics.

Illustrative site-manifest.yaml

schemaVersion: 1
site:
  name: example-architecture-guide
  owner: platform-engineering
  classification: internal
runtime:
  type: static
  outputPath: dist
authentication:
  mode: enterprise-identity
network:
  exposure: private

Illustrative thin Jenkins adapter

governedStaticSite {
    outputPath = "dist"
    classification = "internal"
    runtime = "none"
    authentication = "entra"
    targetEnvironment = "development"
}

Reference patterns only. Map fields, identity, controls, credentials, and approvals to local policy and tooling. These are not drop-in corporate configurations.

Repository supplies

Artifact root
Classification
Owner
Runtime declaration
Approved exceptions

Platform inherits

Qualification
Security controls
Build and package
Immutable promotion
Credentials
Evidence and rollback metadata

Failure returns

Named failed control
Template version
Local reproduction
Artifact identity
Exception route

07 · Security without repetition

Risk-tiered controls, inherited centrally

Control area	S0 · static content	S1 · static application	S2 · dynamic application
Qualification	Static files; no client application logic	Client-side logic or approved API consumption	Server, state, secrets, writes, input, or sensitive processing
Baseline	Secrets, file types, malware, HTML, links, classification, headers, accessibility, ownership, checksum, receipt	All S0 controls	Exit the Static Publishing Lane
Software supply chain	Generated-file provenance where applicable	Locked dependencies, SCA, SBOM, license policy, client static analysis	Organization application-delivery policy
Browser security	Header policy and no unexpected origins	CSP validation, endpoint allowlist, browser security tests	Application threat model and runtime testing
Content risk	Classification, accuracy, privacy, legal, records, export, harm, and audience review remain independent of runtime tier.
Exceptions	Named owner, justification, scope, compensating control, approval, and expiry		Handled by the receiving application lane

Mandatory inheritance

A repository cannot silently omit a required control.

Central versioning

Control changes are pinned, tested, receipted, and deliberately adopted.

Fail closed

Unknown runtime, missing owner, invalid classification, and unmatched bytes stop the lane.

Traceable exceptions

Exceptions are records with expiry, not comments that outlive their context.

08 · Why not Docker?

Portability is valuable. Unnecessary runtime is not.

Containers are justified when the workload needs a server process, runtime-specific behavior, controlled native dependencies, a consistent application execution environment, or an accepted platform boundary. They are weak justification when the only job is serving immutable files.

Question	Static host	Container runtime
Server process required?	No	Yes, or a documented platform constraint requires it
Operational additions	Artifact, host, headers, access, receipt	Registry, image scanning, base-image patching, runtime health, orchestration, capacity
Rollback unit	Immutable file artifact	Image plus runtime configuration
Good reason	Simple static delivery	Real server/runtime requirement or approved uniform platform contract
Bad reason	“Everything goes in Docker” without measuring the additional control and operational surface.

Balanced decision: do not prohibit containers. Require the requirement that earns them.

09 · Azure worked example

A practical hierarchy, not a product advertisement

Capabilities, plan availability, regions, tenant configuration, network design, and enterprise policy can change. Verify the linked Microsoft documentation and local standards during implementation.

Primary
Azure Static Web Apps Standard
Use when purpose-built static hosting, route/header configuration, supported authentication, and the required network posture fit. Microsoft documents preconfigured GitHub and Microsoft Entra ID authentication, route authorization in staticwebapp.config.json, and Standard-plan private endpoints.
Fallback
Azure App Service Linux without a container
Use when Static Web Apps cannot satisfy a requirement but a container still adds no value. App Service documents built-in authentication, private endpoints, access restrictions, diagnostic logs, and deployment slots on supported tiers.
Limited
Azure Storage static website
Use only for deliberately public, anonymous, low-complexity content when limitations are acceptable. Microsoft states that the static website feature does not provide AuthN/AuthZ and cannot configure headers without another service such as CDN.
Exit
Application platform
Use Container Apps, App Service runtime, Kubernetes, or another application platform when server execution, state, secrets, transactions, background work, or sensitive processing makes the workload S2.

External CI

Static Web Apps supports custom source providers through a build job and deployment job using a deployment token. Store the token in the approved secret system, scope access, rotate on exposure or lifecycle policy, and update the calling pipeline after reset.

Identity and network

Authentication identifies a user; route rules authorize access. A private endpoint restricts network reachability and does not replace user authorization. DNS is part of the private-endpoint design.

Central enforcement

Azure DevOps required-template checks can fail a pipeline that does not extend the required template. Approvals and checks live on protected resources rather than in pipeline YAML and can stop a stage before execution.

Promotion

Preserve one artifact checksum across environments. Keep environment routing, identity, and policy outside the artifact where possible; if bytes change, call it a new artifact rather than “the same build.”

Official Microsoft source notes

Documentation reviewed for this candidate on 2026-07-30. The bibliography download records page titles, URLs, and bounded claims used.

10 · Other platforms

Keep the architecture platform-neutral

Purpose-built static host

Managed static-site products, object storage plus an edge layer, or a governed internal static-hosting service.

Replaceable adapter

Jenkins, Azure DevOps, GitHub Actions, GitLab CI, Buildkite, or another approved orchestrator.

Policy and evidence

Central templates, reusable actions, policy engines, signed attestations, and immutable artifact registries.

Decision criteria

Identity, private reachability, headers, custom domains, observability, immutable promotion, cost, support, and exit portability.

11 · Metrics and proof

One successful page is not the success condition.

Baseline the current path before the pilot. Compare the same workload and report the result without manufacturing a victory.

Measure	Current baseline	90-day target evidence
Commit to Development	Elapsed and queue time	Same start/stop definition; lower median and tail
Human work	Manual actions and handoffs	Fewer, with approvals preserved where required
Repository burden	Pipeline lines and credential count	Thin adapter and centrally held environment credentials
Reliability	Failed deployment rate and diagnosis time	Named failure domains and faster reproduction
Evidence	Assembly time and missing artifacts	Automatic human and machine receipts
Recovery	Rollback steps and elapsed time	Redeploy exact known-good checksum
Scale	Second-repository onboarding effort	Materially lower than the first without weaker controls
Governance	Exceptions and inherited controls	Exceptions visible; inherited percentage rising

12 · Serious objections

Challenge the assumption without caricaturing the team

“Security requires the current pipeline.”

List the required controls and prove which mechanism enforces each one. Preserve the controls; replace repository-specific mechanics only when the new lane provides equal or stronger evidence.

“Containers make everything portable.”

They make a runtime portable. A static artifact is already portable across conforming HTTP hosts. Add a container only when its runtime contract earns the cost.

“Static means low risk.”

Static narrows runtime risk. It says nothing about confidentiality, accuracy, malicious content, regulated material, intellectual property, or inappropriate public release.

“Azure DevOps would solve this.”

A new orchestrator can host the same fragmented model. The solution is the reusable contract, qualification, controls, artifact identity, and evidence—not the logo on the YAML runner.

“Build once cannot handle environment configuration.”

Move host, identity, DNS, headers, and environment policy into the deployment plane where possible. When environment-specific bytes are unavoidable, produce a new checksum and stop calling it the same artifact.

“A central platform will become another bottleneck.”

It will if it requires bespoke tickets. Operate it as a self-service product with versioned contracts, clear service levels, observable failures, bounded exceptions, and contribution paths.

13 · Adoption roadmap

Prove the lane in Development before asking for Production

Baseline and contract

Measure one current workflow.
Provision a Development landing zone.
Define S0/S1/S2 and content classification.
Lock the artifact, receipt, ownership, and rollback contracts.

Exit: agreed baseline and approved Development experiment.

Template and negative proof

Implement the central publishing template.
Create the first thin CI adapter.
Prove secret, classification, missing-owner, S2, integrity, access, and rollback failures.
Generate human and machine receipts.

Exit: exact artifact reaches Development without portal deployment.

Second repository and decision

Onboard a materially different second repository.
Compare lead time, handoffs, failures, evidence, and credentials.
Exercise template upgrade and rollback.
Seek local governance approval before any Production use.

Exit: evidence-backed go, revise, or stop decision.

14 · Download the implementation kit

Reusable contracts, examples, receipts, runbooks, and checklists

Sanitized reference material. No credentials, employer-specific policy, production endpoint, or claim of enterprise validation is included.

Standalone edition: binary downloads are intentionally not embedded as data URIs. Obtain the separate implementation-kit or static-directory package from the canonical protected candidate.

Architecture Decision Record
Reference architecture diagram
Workload qualification tree
S0/S1/S2 control matrix
site-manifest.yaml
Thin Jenkins adapter

Azure DevOps consumer
Generic CI adapter contract
Artifact manifest schema
Human and machine receipts
Adoption backlog
Operator and rollback runbooks

Developer onboarding checklist
Production-readiness checklist
Source bibliography
Static-directory publishing contract
Deterministic inventories and hashes
Reference-only limitations

15 · Recommendation

Standardize the publishing system, not the shape of every site.

Give teams a narrow contract, inherited controls, immutable artifacts, observable failures, usable receipts, and a real rollback path. Keep content authority, security judgment, and Production approval intact.

This Development candidate demonstrates the static mechanics. It does not prove adoption results, validate a real enterprise environment, authorize a cloud design, or justify public publication. Those decisions require local evidence and separate authority.

The Governed Static Publishing Lane

Six decisions were welded into one opaque process.

Hosting

CI orchestration

Security controls

Release approval

Evidence

Ownership

View this recommendation as

Provide a deterministic artifact root, not a new platform.

Own the template as a versioned product with thin, replaceable adapters.

Reduce variance while preserving content and runtime risk as separate decisions.

Choose hosting, identity, and network posture from requirements—not habit.

Make ownership, deployed identity, recovery, and retirement visible.

Standardize the paved road and measure whether friction actually falls.

A deterministic educational decision aid

Static content lane

Recommended hosting

Minimum controls

Disqualifying conditions

Unresolved local review

Move the system boundary

Every repository rebuilds the delivery system.

Current: repeated application-scale delivery

Target: one governed contract, many thin adapters

The repository declares intent. The platform supplies mechanics.

Risk-tiered controls, inherited centrally

Mandatory inheritance

Central versioning

Fail closed

Traceable exceptions

Portability is valuable. Unnecessary runtime is not.

A practical hierarchy, not a product advertisement

Azure Static Web Apps Standard

Azure App Service Linux without a container

Azure Storage static website

Application platform

External CI

Identity and network

Central enforcement

Promotion

Keep the architecture platform-neutral

Purpose-built static host

Replaceable adapter

Policy and evidence

Decision criteria

One successful page is not the success condition.

Challenge the assumption without caricaturing the team

Prove the lane in Development before asking for Production

Baseline and contract

Template and negative proof

Second repository and decision

Reusable contracts, examples, receipts, runbooks, and checklists

Standardize the publishing system, not the shape of every site.