DevOps and deployment pipelines
Automated deploys, a hardened edge, tested backups and monitoring for the apps you run.
We run our own products this way, so this is the setup we know works in practice. A deploy should be a merge, not an evening of SSH. Secrets belong in the pipeline's environment, not in the repository. A backup only counts once it has been restored somewhere else.
What we look after
- CI/CD pipelines that build, test and deploy on merge, with staging and production kept separate
- Secrets held in the pipeline's environments, never committed to the repository
- Cloudflare DNS, TLS, WAF rules and tunnels, so servers need no open inbound ports
- Reverse proxy, process manager and container setup on Linux servers
- Database backups to off-site object storage, with scheduled restore tests
- Uptime monitoring and alerts, and a written runbook for the common failures
- Mobile app build and store release pipelines
What do you get at the end?
- Pipelines and server configuration committed to your repositories
- A runbook: how to deploy, roll back, restore a backup and rotate a secret
- A handover so your team can run it without us
How does the engagement run?
A written scope and the access you grant come first. After that, changes happen inside agreed windows and each one goes into a change log you keep a copy of.
Frequently asked questions
Do you host our application?
We can set it up on your servers or cloud account, so you own the infrastructure and the access. We do not hold your systems hostage: everything we build is committed to your repositories and documented.
Who can change production?
Changes go through the pipeline after review. Direct changes on a production server are made only by the people you name, and we write down every change we make.
Tell us what you need looked after.
A short call, then a signed scope. No testing before that.