DevOps & cloud
DevOps & Cloud Infrastructure
I handle the DevOps side: the pipelines, containers and cloud infrastructure that let your team ship every day without fear, on AWS or DigitalOcean, with monitoring that tells you about problems before your customers do.
- Docker
- AWS
- GitHub Actions
- Terraform
- DigitalOcean
- Grafana
Sound familiar?
The problems I solve
Deploys are a manual ritual
Releasing means SSH-ing into a server and running commands from memory. Only one person knows the steps, and every release feels risky.
You find out about outages from customers
There are no health checks or alerts, so the first sign of trouble is an angry email or a drop in sales.
The cloud bill keeps growing
Servers were added over time and nobody is sure what each one does, whether it is still needed, or why it costs what it does.
Nothing is written down
Infrastructure was clicked together in a console. If the server died tonight, rebuilding it would take days of guesswork.
What I build
What you get with DevOps & Cloud
CI/CD pipelines
GitHub Actions pipelines that test, build and deploy on every merge, with preview environments and one-click rollbacks. Releases become routine, not events.
Docker and containers
Applications containerised with lean, secure Docker images and consistent environments from a laptop to production, so “it works on my machine” stops being a problem for your team.
AWS and DigitalOcean setups
Production-ready hosting on AWS or DigitalOcean: networking, databases, storage, SSL and access control set up properly.
Infrastructure as code
Infrastructure defined in Terraform so it can be reviewed, versioned and rebuilt reliably instead of living only in a console.
Monitoring and alerting
Uptime checks, logs, metrics and alerts to Slack or email, so problems are caught and diagnosed quickly. Dashboards show response times, error rates and resource usage in one place.
Backups and hardening
Automated backups with tested restores, security updates, least-privilege access and a written runbook for common incidents, so anyone on your team knows what to do when something breaks.
See it in action
From git push to production
Hover, tap or tab through the steps to see what each one does. Press Run to replay the demo.
- git push to main: A merged pull request on main starts the pipeline automatically.
- Test & build: GitHub Actions runs linting, tests and the production build; any failure stops the release.
- Push Docker image: A versioned Docker image is built and pushed to the container registry.
- Deploy to AWS: The new version rolls out on AWS with zero downtime and an instant rollback path.
- Health checks: Health checks and metrics confirm the release is healthy before old versions are retired.
- Alert on failure: If anything looks wrong, the team gets a Slack alert with logs and a rollback link.
git push to main: A merged pull request on main starts the pipeline automatically.
How we work
From first call to handover
Discovery call
A free call to understand your goals, current tools and constraints. You leave with a clear idea of what is possible, even if we do not work together.
Scope & quote
A written scope with deliverables, milestones and a quote, so you know exactly what you are getting before any work starts.
Build in weekly milestones
Work ships in weekly slices with a preview link and a short update each time, so you see progress and can steer early.
Handover, docs & support
You get the code, accounts, documentation and a walkthrough video. Ongoing support is available if you want it.
FAQ
DevOps & Cloud questions
DigitalOcean is simpler and very cost-effective for most small and mid-sized apps. AWS makes sense when you need its wider range of managed services, stricter compliance, or more complex scaling. I recommend one based on your app, your team and your budget. Either way, everything is set up with infrastructure as code, so moving between providers later is a planned project rather than a rewrite.
Yes. I start by documenting what you already run, then improve it step by step: pipelines first, then containers, monitoring and infrastructure as code, without a risky big-bang migration. Each step is tested in a staging environment first, and nothing changes in production without a rollback plan agreed in advance.
Often, because the audit usually finds unused resources and oversized servers. I show you what each resource costs and what I would change before touching anything. Typical savings come from right-sizing servers, removing forgotten resources and using reserved or committed pricing where it makes sense, but I only recommend changes I can explain line by line.
Yes. After handover I can stay on for maintenance, updates and incident support, or simply be available when your team needs help. We agree the support arrangement during scoping, and every incident gets a short written summary of what happened and how it was fixed.
Most products do not. Containers on a managed service or a well-configured server are simpler and cheaper to run. I only recommend Kubernetes when your scale or team genuinely needs it. Starting simple keeps your monthly bill and maintenance work low, and the setup can still grow into Kubernetes later if the product truly needs it.
Secrets live in a proper secret store or encrypted CI variables, never in the repository. Access follows least privilege, and you keep owner access to every account. I also enable audit logs and multi-factor authentication on cloud accounts, and document who has access to what, so offboarding a team member is quick and safe.