Short, reproducible notes about static websites and small service operations.
These notes focus on the boring parts of running a small service: clear defaults, observable failures, repeatable releases, and recovery that has been exercised before it is needed.
The current collection is organized around four recurring questions:
What does the protocol or server actually promise?
Which headers, files, and logs make that promise visible?
What can be checked without changing production state?
Which source should an operator read when the example is not enough?
Examples are intentionally small. Adapt paths, users, and policies to the environment where you run them. Every note ends with a short source list instead of copying vendor documentation into this site.
A maintenance timer should leave its last result visible
Scheduling is only half the job; operators also need to see when the task last ran and how it ended.
Restart policies need a rate limit
Use an explicit service type, bounded restart behavior, and start-rate limits that leave evidence in the journal.
A release checklist for a static site
Verify the artifact before replacing the live directory, and keep the checks close to the release command.
SSH host keys are part of the deployment record
Record the expected fingerprint, use a deliberate StrictHostKeyChecking policy, and treat changes as an incident until explained.
The advantage of small systems
Small does not mean unfinished; it means each boundary has a clear job and a visible owner.
Security headers should describe the actual page
Start with a narrow policy, then expand it only when a documented feature needs another resource.
robots.txt and sitemaps answer different questions
robots.txt is a crawler-facing preference; a sitemap is a URL inventory; neither is an authorization layer.
Reliable defaults beat clever recovery
Keep the common path explicit, observable, and safe to repeat before adding recovery branches.
