My static site's visitor counter reset to 1. Here is the deploy checklist I wish I had

A few hours after a successful deploy, I opened my own site and saw the kind of number that makes you immediately stop doing everything else:

Total visits: 1

That was not a new project. It was not a fresh database. It was not supposed to say 1.

For context, I have been building entry for the release because this kind of tiny infrastructure work is easy to forget. The code change may be one line, but the operational lesson is much bigger.

My new tiny-site deploy checklist

Here is the checklist I am using now.

1. Classify every path before deleting anything

Before a full replacement deploy, split files into categories:

build artifacts:

  public/*.html

  public/assets/**

  public/tools/**



runtime data:

  public/data/visits.json

  uploads/

  cache/

  queues/

  generated reports

  anything written by production code



secrets/config:

  .env

  config/*.php

  server-only keys

If a production process writes it, the deploy script should not casually delete it.

2. Preserve runtime data explicitly

Do not rely on “it is probably in the package” or “the backup exists somewhere.”

Make the restore step part of the deploy script:

RUNTIME_DATA_BACKUP="${BACKUP_DIR}/public/data"



# after extracting the new package

if [ -d "$RUNTIME_DATA_BACKUP" ]; then

  mkdir -p "$SITE_DIR/public/data"

  cp -a "$RUNTIME_DATA_BACKUP/." "$SITE_DIR/public/data/"

fi

Explicit beats remembered.

3. Verify the values users can see

Do not only check whether the deploy command exited successfully.

Check the thing the user will notice:

Homepage loads

Language switch renders the expected language

Changelog shows the newest version

Visitor stats did not reset

Critical assets use the new cache-busted URL

A deploy that returns DEPLOY_OK can still ship a bad state.

4. Keep one small audit script per scary class of bug

I now prefer small, boring verification scripts over trying to remember every edge case manually.

Examples:

verify homepage i18n keys

scan changelog asset versions

check broken internal links

check missing hreflang tags

scan for mojibake signatures

verify visit stats after deploy

The best audit scripts are not clever. They are just executable memory.

5. Write the postmortem while it is still embarrassing

This is the part I recommend most.

When the bug still feels annoying, write down:

• what happened


• why it happened


• what file caused it


• what exact check would have caught it


• what rule changes now

A week later, you will remember “the stats bug.” You may not remember the exact path, command, backup, and prevention rule.

Future-you needs the boring details.

A small ask

One practical problem with small independent tools is discovery. Search engines trust links, and new projects do not have many.

If you maintain a list of privacy-friendly tools, browser-based utilities, frontend resources, or “no upload” image tools, and you think this project belongs there, a mention or backlink to 24Picture's zero-upload image tools would genuinely help.

No pressure, and please do not link it if it is not useful for your audience. But if it fits, that kind of independent web curation is still one of the best ways small tools get found.

I am also happy to look at useful directories, resource lists, or indie tool pages in return. Good lists deserve links too.

Wrap

The bug was small. One JSON file disappeared.

But the lesson was bigger: static deploys are only simple if everything is actually static.

The moment a production process writes a file, even a tiny one, your deploy script has to treat it as state. If it does not, the script is not just deploying your site. It is editing your production data model.

And sometimes the first sign is a very loud number:

1