01
Production topology
App, API, database, storage, and how they talk. We keep it as simple as the product allows, complexity is a cost you pay every month.
Service 05
Architecture that stays quiet in production.
Cloud work here is not a slide with logos. It is how the app is deployed, how it fails, and how the next release gets out.
Typical start
Infrastructure read in week one
Build length
2–6 weeks to a stable production path
Best for
Launch hardening and scale-up
The problem
The product runs on a single VPS nobody documented, deploys are FTP, backups are a hope, and the person who ‘knows the server’ is also the founder. That holds until traffic, a staff change, or a disk filling up at 2am.
What you walk away with
A deployment you can explain, environments that match, monitoring that pages a human, and a path to scale without throwing the first version away.
Who this is for
- Teams going from ‘it runs on my laptop / one server’ to something they can sell
- Companies whose uptime now has a contract attached to it
- Products about to put a mobile app in the stores and need the API to keep up
- Companies that need an engineering team to own production, not a single freelancer
What this service actually includes
02
CI/CD & releases
A pipeline from git to production with staging in between. Releases become a button and a checklist, not a weekend.
03
Linux & runtime
Hardened servers, process management, TLS, and the unglamorous work that stops a box becoming a mystery.
04
Observability & backups
Logs, uptime checks, error tracking, and backups you have actually restored once. If you have not restored it, it is not a backup.
Typical company engagements
First production path
Staging + production, TLS, deploys from git, backups, and a runbook. The minimum a company should sell software on.
Hardening before a store launch
The API behind a new mobile app: capacity, monitoring, and a rollback so review-week traffic is boring.
Estate cleanup
Document the real servers, secrets, and DNS. Then make deploys repeatable so the founder is not the bus factor.
How the work runs
Step 01
Read the current estate
Servers, domains, secrets, and the deploy path as it really is, not as the last contractor described it.
Step 02
Target architecture
A diagram and a bill of materials you can afford. We choose managed services when they buy sleep, and VPS when they buy control.
Step 03
Move without drama
Staging first, then cutover with DNS, TLS, and a rollback. The goal is a boring launch.
Step 04
Operate
Runbooks, alerts, and a monthly pass if you want us to stay on the system rather than vanish after go-live.
Deliverables
What a company can put in a statement of work.
- Documented architecture and environment map
- Staging and production environments
- CI/CD pipeline from repository to release
- TLS, backups, and basic monitoring
- Runbook for deploys, incidents, and restores
What the company keeps
Ownership and handover are part of the professional standard.
- An architecture diagram that matches reality
- Staging and production you can name
- A pipeline from repository to release
- Backups that have been restored once, on purpose
How a company starts
Send this and we can quote.
You do not need a 20-page RFP. A messy but honest brief is enough for a scoped proposal.
- 01
Where it runs today (VPS, shared hosting, a cloud account, or ‘on a laptop’)
- 02
Domains, DNS, and who currently has the keys
- 03
How you deploy (git, FTP, ‘we ask someone’)
- 04
Uptime expectations, nice-to-have vs contractual
- 05
Whether a mobile or web launch is about to put load on this
Stack
Tools we actually ship with. We will work inside yours if that is the cheaper path.
LinuxDockerCI/CDNode.jsNginxCloud VMs / managed DBs
What this is not
Saying no is how companies know we are not selling everything.
- 24/7 NOC staffing. We set alerts and runbooks, we are not a call centre
- Kubernetes for a product that still fits on two machines
- Cloud cost theatre with no application changes
Questions companies ask
Do we have to use AWS?+
No. We pick the provider that matches the product and the team who will operate it. A well-run VPS beats a neglected AWS account. If you already live in a cloud, we work there.
Can you work with our existing DevOps person?+
Yes. We are happy to own the application side and pair on infrastructure, or to cover that layer with our team until you hire DevOps.
Is this a one-off or ongoing?+
The first engagement gets you to a production path you can live with. After that, a light retainer covers patches, capacity, and the next feature’s infrastructure.
Will you hold our production passwords?+
Access sits in your accounts. We use named users or a vault you own. When the engagement ends, our access is revoked. That is non-negotiable.
What if we are still on one VPS?+
That is a normal starting point. We document it, add staging, backups, and a real deploy path, then scale only when the product needs it.
Discuss cloud with us
Tell us what you need: a new product, a revamp, or ongoing maintenance. You will receive a clear response on fit, scope, and next steps.