Engineering note / Deployment practices
Ship the change you intended.
A release should have a known scope, a recoverable starting point, and evidence that the intended version—not just some process—is serving users.
Last reviewed
On this page
Separate source from deployed state
A working tree, a commit on the main branch, and a running application are three different observations. I use deployment markers, image revisions, and application health endpoints to connect them.
That distinction matters in a household environment where multiple projects evolve at once and a shared host serves several applications.
Keep the blast radius small
Fed Forager’s public edge also routes other sites. Its application release must not casually replace the shared proxy configuration. Workbench has its own Compose project and data directory, while joining the network needed for proxy routing.
The family portal is static HTML, CSS, and JavaScript. A content release can therefore be a selective static-file deployment rather than a container rebuild or proxy reload. Generated status files and unrelated prototypes should not be swept into that release.
Capture the recovery point first
Before a database migration, capture a consistent backup and identify the applicable recovery path. Some schema changes need a compatible forward fix rather than a blind code rollback.
For static files, an external backup of the affected served paths makes rollback straightforward. The backup belongs outside the served root, where it cannot accidentally become downloadable site content.
Verify behavior at the right layer
- Run focused checks against the candidate source.
- Check the release artifact and migration prerequisites.
- Deploy only the intended services or files.
- Verify the deployed revision and health.
- Exercise appropriate user journeys and observe the result.
Production-writing tests need a different decision from read-only verification. A test that submits a form, sends an alert, or changes household devices is not merely a harmless page check.
Small details with large consequences
- Environment variables: restarting a container does not apply a changed env file; recreate the affected container.
- Bind-mounted configuration: replacing a single file can leave a container attached to the old inode. Validate what the running process actually sees.
- Static content: compare checksums of the intended release files rather than assuming a successful copy proves the right content shipped.
- Documentation: record the deployed state and verification limits, not only the desired final state.
These practices keep a small environment understandable. They also make it much easier to hand work to another operator.