Infrastructure
Self-hosted infrastructure migration
Moved Umi's client sites onto infrastructure we control and cut builds from 15 minutes to 2–3.
- Role
- Lead developer
- Year
- 2025
- Stack
Results
What changed
15 min to 2–3 min
Build time per deploy after moving to cached container builds
Umi Digital
Why move off managed hosting#
Every client site deployed through one shared pipeline. Builds queued behind each other and took around 15 minutes, and when one failed it was hard to see why. The goal was to own the infrastructure and make deploys boring.
What changed#
- Each site builds from a shared, cached base image
- CI runs per site, with dependency caches kept between runs
- Runtime and
postgreslive on servers we manage
# Shared base: dependencies cached once, reused by every siteFROM node:22-alpine AS depsWORKDIR /appCOPY package.json pnpm-lock.yaml ./RUN corepack enable && pnpm install --frozen-lockfile
FROM deps AS buildCOPY . .RUN pnpm buildBuilds now take two to three minutes, and the setup is documented so the rest of the team can run it without me.
Process
How it was rolled out
Audit
[What was measured first: build times, costs, failure points.]
Pilot one site
[Which site went first, and what it proved.]
Migrate in batches
[How the rest moved without downtime.]
Hand over
[Runbooks, alerts and who owns what now.]
Hiring, or have a project in mind?
Open to lead and senior engineering roles, and to freelance work.
More work
Related projects
One shared Next.js and Payload platform behind Umi's hospitality client sites.
Versioned UI and config packages, so a fix lands everywhere with one bump.