BEMRIX / CLOUD & DEPLOYMENT
A release with
a way back.
From a working website to a repeatable release. Packaging, verification and recovery preparation for our own digital home.
Internal engineering project · Verified locally · Public hosting pending
THE CHALLENGE
A successful build
is just the beginning.
A website also needs the right files on the server, a useful health signal and a clear response when a release fails. We used BEMRIX itself to make those steps concrete.
The result is a portable release workflow and an operational handover. The public domain, hosting account and live infrastructure are still to be selected.
THE RELEASE PATH
Build confidence.
One check at a time.
Check the source
Locked dependencies, type checks and focused regression tests.
Package the release
Standalone server, public assets and a file integrity manifest.
Prove it runs
Start the packaged application in isolation and check real responses.
Keep a way back
Retain the previous package and rehearse its return to service.
EVIDENCE, WITH CONTEXT
What we checked.
The packaged website
An independent Node process serves the built release, including pages, styles, optimized images and downloadable files.
- Uncached process health response
- Four key pages and their stylesheet assets
- Image optimization and public downloads
- Preview indexing rules and a real 404
Useful when things go wrong
The checks reject HTTP errors, incorrect health payloads, redirects, cached responses and timeouts. File hashes catch missing or changed package contents.
A local recovery rehearsal returns to a retained build. It does not demonstrate a live traffic switch or zero downtime.
A workflow the next person can follow
A GitHub Actions definition, build instructions, a one-shot health command and a release / rollback runbook accompany the project.
The workflow has not run on GitHub. Hosting, TLS, alert delivery and backup recovery still require environment-specific verification.
OPERATIONS, MADE EXPLICIT
Know what to watch.
Know how to recover.
Process health is one signal, not an uptime promise. The handover defines the checks to repeat after a release, what a rollback restores and what remains outside this website’s current scope.
Read the release runbook ↓npm run check:health -- \
http://127.0.0.1:3001
GET /api/health/
{
"status": "ok",
"service": "bemrix-web"
}Checks this process only. No database, scheduled monitor or alert provider is connected.
THE NEXT ENVIRONMENT
Ready for a hosting decision.
After a domain and provider are agreed, the next phase is to build for the target platform, configure HTTPS and the process manager, verify the enquiry journey, connect alerting and rehearse recovery on that infrastructure.
Explore Cloud Services →Let’s make it happen