galenry.Make shipping boring on purpose
Releasing should be the least interesting part of the week. We put the pipeline, the infrastructure definitions and the alerting in place, so deploying is routine and on-call stays quiet.
The shape of the work
Agreed before we start. You own everything we produce, whether or not you continue with us.
- Starts with
- Delivery + infra review
- You get
- Pipeline + infrastructure in code + alerts
You are probably here because of one of these. Each one points to where we’d start.
- 01
What you are seeing
Deploys that happen on Friday only if someone is brave
The question it raises
Why does deploying still take a person and an afternoon?
Where we’d start
- One automated pipeline with a tested rollback
- 02
What you are seeing
Staging that does not match production closely enough to trust
The question it raises
Can we rebuild this environment if we lose it?
Where we’d start
- Every environment defined in code
- 03
What you are seeing
Alerts that get acknowledged and ignored
The question it raises
Why is on-call being paged for things nobody acts on?
Where we’d start
- Alerts on what users feel
- 04
What you are seeing
Shared credentials in a password manager
The question it raises
Where are our production credentials, and who can use them?
Where we’d start
- Short-lived credentials, scoped to each job
None of these sound right? Tell us what is actually happening.
Describe the problemWhat makes a release boring. Not all four land in every engagement.
Every check automated
Tests, build, staging and production run as one pipeline. Nothing reaches production by hand, and rolling back takes one command.
Infrastructure defined in code
One definition for every environment, so staging really resembles production and a new environment is a config change.
Alerts on what users feel
We page on slow responses and errors users actually see, so on-call is only woken for things that matter.
Short-lived access
No long-lived keys in the repo or the pipeline. Each person and service gets access limited to the job, and it expires by itself.
How the engagement runs. The shape holds; the depth of each phase moves with the problem.
Review
We look at how a change actually reaches production today, where it waits, and what breaks when it goes wrong.
You get
Delivery assessment
Pipeline
Automated build, test and deploy, with a real staging environment and a rollback that has been tried.
You get
Working pipeline + rollback
Infrastructure
Environments defined in code, secrets moved to short-lived access, and permissions limited to each job.
You get
Environments in code + access model
Monitoring
Dashboards and alerts tuned to what users feel, with a runbook for every alert that can wake someone.
You get
Alerts + runbooks
What we can point at. Including where we cannot.
No cloud partner status or team certifications
We hold none, and would rather say so than imply otherwise. Ask us to walk through a pipeline we have built instead.
Where we work day to day
Vercel and AWS in production across our own products; GCP and Kubernetes on a smaller number of engagements. We will tell you which of those is a stretch for us.
Every product we run ships through the pipeline described here
Automated checks, infrastructure in code and short-lived access: the same setup shown on this page.
See itWhat we reach for first. Not the only things we work with, and we change them when there is a reason.
Cloud
Whichever your business already runs on. We will say if one is a stretch for us.
- AWS
- Azure
- GCP
- Vercel
Infrastructure
Environments defined in code, so they can be rebuilt and kept alike.
- Terraform
- Containers
- Kubernetes
Delivery
Every change takes the same route to production, and the way back is tested.
- GitHub Actions
- Staged deploys
- Rollback
Operations
Alerts on what users feel, each with a runbook for whoever gets paged.
- OpenTelemetry
- Grafana
- Runbooks
Tell us what you’re trying to build. We’ll tell you where we’d start.
Bring an idea, a stalled project, or a system that has outgrown itself.
Send us a brief
The problem, what you have tried, and what success looks like. A few lines is enough to start.
Prefer email? contact@galenry.com
What happens next
- 01Reply within one business dayFrom one of our engineers.
- 02First call: 30 minutes, no deckA working call about the problem. We ask questions rather than present slides.
- 03An honest answerWhere we would start, or, if we are not the right team, who might be.