stalance/services/cloud-operations
Deploys nobody notices.
Releases that nobody notices, monitoring that pages us when something breaks, and admin tools that are not on the public internet.
- in production
- For our own 20+ storefronts
- deploys
- Rolling, without dropping requests
- monitoring
- We watch it and get paged when it breaks
What we build
Zero-downtime web deploysReleases roll out without dropping requests, behind health checks that mean something.
Queues per tenant and priorityOne noisy tenant cannot starve the rest, and urgent work does not wait behind bulk work.
Monitoring and pagingWe watch the system and get paged when it breaks.
Private admin accessAdmin tools sit behind a mesh VPN, and firewalls are applied when a server is provisioned, not afterwards.
How we would approach yours
01 readRead the incidentsYour last few outages, alerts and deploys. What woke someone and what should have.02 deployMake deploys boringSmall, reversible releases and health checks that mean something.03 alertAlert on symptomsAlerts that point at what users feel, not only at exceptions.04 runbookWrite the runbookFor the parts that bite, in words your team will actually use.Questions engineers ask us
Do you run on our cloud account?
Either is possible. We agree it in the written scope.
Is there on-call cover?
It depends on the engagement. We agree it in the written scope.
Can you fix deploys without replatforming?
Usually. Better deploys are changes to how you release, not to what you run.
Tell us what is broken
One paragraph is enough. An engineer reads it, not a ticket bot.