Save, publish and deploy

Reading time 5 min

Find the first mismatched layer before trying to repair stale content. Browser text, saved source, built output, Git and actual host are distinct. Success at one does not prove the next happened.

State map

Action Changes
Keep draft Browser-local recovery only
Save Server source or its separate form settings
Publish Changes Shared local output from saved inputs
CLI build Chosen output; not editor marker automatically
Git commit/push Version-controlled files, not unsaved tabs
Remote deployment Reader-host artifact under pipeline rules
Cache refresh Client/host view, not source repair

None of these automatically saves an unsaved tab on another device. Browser Save/Publish does not commit/push/upload. A source-repository push deploys only if your external pipeline is configured for it. Document actual pipeline trigger/output, not an imagined connection.

For this showcase, documented rendered-output publication and Cloudflare host are separate from the optional editor. That is this site’s workflow, not a universal V2 default integration.

Follow one fictional change

  1. Select Field Guide’s intended workstation source path.
  2. Edit a sentence; it is currently browser text.
  3. Save and wait; reopen/inspect confirmed server source.
  4. Review all saved work included in upcoming build.
  5. Publish/build and inspect local generated reader.
  6. Record reviewed source/artifact checkpoint.
  7. Release exact artifact using chosen hosting workflow.
  8. Open actual host route/search/media and verify task.
Evidence Answers
Text on screen What this browser currently holds
Confirmed source What source server confirmed
Built artifact What generated artifact contains
Provider deployment result What provider accepted and released
Live responses What reader actually receives

The optional preview is not deployed-reader snapshot. Its plugins/media/link context differ. Browser recovery is not server backup, and generated HTML does not reconstruct users/settings/history/source intent.

Shared publication inputs

Administrator Publish starts one process-shared job over saved source, not selected page or only initiator’s changes. It snapshots content/static/templates/site config and selected runtime branding/link data. Accounts/audit history are not public build input.

Unsaved tabs/drafts are excluded. Other writers’ saved pages can be included. Ask writers to save/review and coordinate a publication window; application has no per-page approval queue or selective “publish my page only” gate.

A source change during job can leave new unpublished state after completed output. Fingerprint uses paths/size/mtime/folders, not content-byte integrity; equal-size/time changes can evade indication. Inspect actual source/artifact when completion matters, not badge alone.

Local stage boundaries

Stage Responsibility
Check Snapshot saved inputs
Build Temporary output through builder
Verify Expected generated result checks
Switch Replace selected local reader output
Post-switch Marker/log/history/backup warnings possible

Before-switch build/check failure leaves old output untouched. Switch/permission/disk errors need actual state inspection; do not universalize “all failures keep old site”. Publisher attempts restoration where supported and retains prior output when backup rotation succeeds, but there is no one-click UI rollback guarantee.

Closing progress does not cancel job. A second administrator can observe same running publication; repeated start is refused while busy. Restart loses in-memory job view and does not prove it finished. Preserve diagnostics/output state before another attempt.

History/marker write failures can follow completed output replacement. Read returned stage/live message and actual filesystem rather than treating missing log as no action. Publishing stages gives exact engine stages/limits; Security and history explains recorded summaries.

Git is separate

Browser saves do not automatically commit, push, open review or enforce approval. Git history exists only when chosen files are actually tracked/committed. Private runtime must not be added just because it sits near source.

A generated-output repository is a release artifact workflow; a source repository is a build pipeline workflow. They have different roots, dependencies and secrets. Do not confuse pushing source with uploading ready output. Build workflow and provider chapters distinguish those paths.

Deploy exact reviewed artifact

Check Why
Intended host/project/branch Wrong destination can look successful
Output root index.html belongs at configured root
All resources/index HTML and search/styles must match
No private bytes Upload output, not whole checkout/runtime
Old files Add-only uploads can retain removed content
Prefix/redirects/404 Provider behavior differs from local map
Cache Origin/deployment before blaming browser

After provider reports success, inspect home, deep route direct reload, assets, search heading, diagrams/downloads and true missing URL. Following one homepage is not whole artifact verification. Source/editor account protects writing, not reading; private host gate must cover all bytes.

Do not use repeated build/deploy as a diagnosis when project/branch/output root is wrong. Preserve good source/artifact while repairing host. No V2 default scheduled release, automatic remote upload or source approval service is provided.

Stale-content decision table

First mismatch Next check
Browser text only Save intended text, preserve recovery
Server source wrong Correct source/merge manually, not deploy
Source current, output old Build/publish correct inputs/data
Output current, host old Provider project/branch/artifact/log
Host origin current, browser old Cache and exact URL
Search old, pages current Deployed/cached index alignment
Route moved Source title/host redirect/obsolete files

A session/access error needs private sign-in/grant handling, not public deployment. Ordinary Markdown Save has no general stale conflict guard; compare other writers’ changes before overwriting. A “Saved” state for unchanged text can avoid new request and does not validate server freshness.

Completion and recovery

A release is complete when intended source is saved/reviewed, artifact correct, actual host current and required reader tasks work. Record engine/source/runtime choices, reviewed artifact and observed host result with remaining caveats.

Failure Recovery layer
Lost unsaved text Browser recovery if available, not guaranteed
Accidental source deletion Git/protected source backup
Wrong reader artifact Prior reviewed output and host rollback
Runtime account/config loss Protected runtime recovery
Host-only failure Repair host while retaining good source/artifact

Backup and restore owns rehearsal. Old HTML does not restore private accounts/customizations; restoring runtime does not restore current sessions. Treat recovery as a checked procedure, not an implicit button behavior.