Automating a broken process
Scripting a workflow nobody understands just produces mistakes at machine speed. Fix and document the process first; automate the good version.
ranjan@ranjan.info:~$ man services/devops-automation
DevOps & Automation
Automate the work your team keeps doing by hand
Every ops team has a list of tasks that are "too small to automate" — done weekly, by hand, forever. I turn those into scripts, pipelines, and dashboards: deployment that doesn't need a checklist, provisioning that doesn't need a person, and monitoring that pages before customers do. Built on your stack, documented, and handed over as yours.
What is infrastructure automation?
Infrastructure automation is the conversion of repeated manual server work — deployments, provisioning, monitoring responses, backup verification — into scripts, pipelines, and integrations that run without a human. Good automation is idempotent (safe to run twice), version-controlled, alert-connected, and documented for handover. The payoff compounds: every automated task is one your team never does again, and one that stops depending on memory to happen correctly.
Written by Ranjan Chatterjee, Infrastructure Consultant · Linux Server Specialist · 15+ years in production Linux · Last reviewed
ranjan@ranjan.info:~$ dmesg | tail
Signs you need this now
Manual ops doesn't announce itself as a problem — it just quietly eats the calendar. Recognize any of these weeks?
- The same server tasks get done by hand every week, from memory
- Deployments follow a checklist in someone's head — and fail when they're on leave
- Setting up a new server takes days of copy-paste from old notes
- Outages are reported by customers before any system notices
- Backup "verification" means assuming the cron job worked
- Billing, panel, and DNS systems don't talk — humans re-type between them
- One engineer is the deployment process
- Growth plans stall because ops capacity is already saturated
ranjan@ranjan.info:~$ cat scope.txt
What this covers
- Bash automation for server management and maintenance
- Python tooling for ops workflows and integrations
- PHP automation — WHMCS hooks, panel APIs, internal tools
- Automated server deployment and provisioning
- Monitoring agents and alerting pipelines
- Backup automation with verification, not just cron and hope
- API integrations between panels, billing, DNS, and cloud providers
- Infrastructure dashboards and custom management portals
ranjan@ranjan.info:~$ man first-aid
How to pick your first automation
The first project decides whether automation sticks. Five steps to choose one that pays for itself visibly.
-
1
List what your team does repeatedly
One week of honest notes: every task done more than once, who did it, how long it took. The list is always longer than anyone expected — that's the point.
-
2
Score by frequency × pain × risk-if-wrong
The best first automation is frequent, annoying, and low-blast-radius. Leave the scary once-a-year migration script for later; automate the thing that steals every Tuesday.
-
3
Define "done" before writing anything
What exactly does success look like — command output, alert fired, report emailed? Automation without a definition of done becomes a script nobody trusts.
-
4
Automate it, version it, alert it
The script goes in Git, runs on a schedule (cron or systemd timer), and reports failure loudly. Silent automation is worse than manual — manual at least knows when it didn't happen.
-
5
Measure the hours it retired
Count what the task used to cost and what it costs now. That number funds the next automation — and turns "we should automate more" from a feeling into a budget line.
ranjan@ranjan.info:~$ grep -i "oops" ~/incidents.log
Mistakes that give automation a bad name
Every one of these comes from a real engagement — usually from before I was called.
Scripts that live on someone's desktop
Untracked scripts with no owner become the mystery infrastructure of next year — nobody knows what runs, where, or why. Version control isn't optional; it's what makes automation an asset instead of a liability.
Cron-and-hope
A scheduled job with no failure alerting is a time bomb with a calendar. Every automation needs to announce its failures louder than its successes.
Over-tooling small infrastructure
Kubernetes for two servers, Terraform for one VPS, a CI platform for a weekly script — the maintenance burden of heavy tooling can exceed the manual work it replaced. The right tool is the smallest one that's reliable.
Secrets hardcoded in scripts
API keys and passwords pasted into automation spread through Git history and backups forever. Secrets belong in environment files or a secret store with restricted access — retrofitting this later is painful; starting with it is free.
ranjan@ranjan.info:~$ diff --options
DIY, provider support, or a specialist?
An honest comparison — each option is right in some situations, including the free ones.
| Option | The right choice when… | Limits & risks |
|---|---|---|
| Off-the-shelf SaaS tools | Standard problems with standard shapes: uptime monitoring, simple deploy pipelines, backup services. Fast to adopt, no code to own. | Monthly costs stack up, integrations end where their catalog ends, and your weirdest workflow — the one eating the most time — is exactly what generic tools don't cover. |
| Internal developer time | Your developers know the business logic, and small glue scripts inside their own product are natural work for them. | Ops automation keeps losing sprint-priority battles to features — the backlog item that's always next sprint. And app developers often lack the sysadmin instincts (idempotency, failure modes, permissions) that make infra automation safe. |
| Specialist build | Infrastructure-shaped automation: provisioning, panel/billing integration, monitoring pipelines, backup verification — built by someone who has operated the systems being automated. | A real project cost up front, and it needs your API access and a handover window. Insist on Git, docs, and secrets discipline as deliverables — with them there's no lock-in; without them you've bought a dependency. |
What you get
- Working automation in production — versioned in Git, not a script on someone's desktop
- Documentation and handover so your team owns and can extend it
- Measured time savings: the manual hours the automation retired
Why work with me on this
- 15+ years inside production Linux — this exact work, done at fleet scale
- Founder-operator of two hosting platforms: I've owned the uptime, not just the ticket
- Every change documented and reversible — you keep a written trail, not a mystery
- Plain-language updates and honest timelines you can plan a business around
ranjan@ranjan.info:~$ ./engage --how
How it runs
The same disciplined path on every engagement — scoped, planned, executed with checkpoints, handed off clean.
-
01
Scope
A short brief or call to understand your stack, the real problem, and what a good outcome looks like.
-
02
Plan
A clear architecture plan — steps, risks, rollback and timeline — agreed before anything touches production.
-
03
Execute
Hands-on work with checkpoints. You see progress; nothing changes on your servers silently.
-
04
Handoff
Documentation, access cleanup and a clear path for what comes next. No lock-in, no mystery.
ranjan@ranjan.info:~$ faq --service devops-automation
Common questions
We're not a "DevOps shop" — is this still for us?
Especially for you. The biggest wins come from teams doing everything manually, because the first automations remove whole categories of work. No Kubernetes required — a well-built Bash script in cron is honest automation.
What does a typical automation project cost?
Defined automations are fixed-price after a short scoping conversation — you know the number before work starts. Teams retiring manual work steadily use monthly engineering blocks instead. Either way, the scoping includes an estimate of hours the automation will save, so the ROI math is on the table from day one.
What kinds of automations do you actually build?
The recurring hits: server and account provisioning, deployment scripts that replace checklists, backup pipelines with verification and alerting, monitoring agents and escalation, WHMCS/panel/DNS integrations, and small ops dashboards. If your team does it by hand more than weekly, it's probably on this list.
How long does a small automation project take?
Most single-purpose automations — a provisioning flow, a verified backup pipeline, a deployment script — deliver within one to two weeks including testing and handover. Larger integrations and dashboards are staged so something useful ships early rather than everything shipping late.
Will we be locked into your tooling?
No. Everything is built on standard tools, committed to your Git, and documented for handover. The explicit goal is that any competent engineer can maintain it after me.
Can you integrate with WHMCS / our control panel / our cloud provider?
Almost certainly — WHMCS hooks, cPanel/DirectAdmin APIs, Cloudflare, and the major cloud APIs are the integrations I build most. If it has an API, it can join the pipeline.
Who maintains the automation after handover?
Your choice: your team, using the documentation and repo that come with delivery, or a small maintenance block with me for updates as your stack evolves. Well-built automation on stable systems mostly just runs — maintenance spikes only when the things it talks to change.
Can you work with the scripts we already have?
Yes — existing scripts usually encode real operational knowledge worth keeping. The typical upgrade path is: move them into Git, add failure alerting, remove hardcoded secrets, make them idempotent, and fill the gaps — evolution, not a rewrite for its own sake.
Do we need Docker or Kubernetes for this?
Only if your problem actually calls for it. Containers earn their keep for consistent deployments and multi-service apps; Kubernetes earns its keep at a scale most businesses genuinely never reach. Right-sized automation on plain Linux beats an over-engineered platform someone now has to maintain.
How are credentials and API keys handled?
Never hardcoded. Secrets live in environment files or a secret store with restricted permissions, out of Git history from the first commit, with rotation documented in the handover. Automation that weakens your security posture is a net loss — this is non-negotiable in everything I ship.
ranjan@ranjan.info:~$ man glossary
Terms from the automation world
Plain-language definitions — so the report reads like information, not incantation.
- Idempotent
- Safe to run repeatedly — the second run changes nothing if the first succeeded. The single most important property of ops automation.
- Provisioning
- Turning "we need a new server/account" into a running, configured result without a human following a checklist.
- Cron / systemd timer
- The schedulers that run automation on time — reliable, boring, and behind most of the world's working automation.
- Webhook
- A system calling your code when something happens (payment received, alert fired) — the glue of event-driven automation.
- API integration
- Systems talking directly — billing to panel, panel to DNS, monitoring to messaging — instead of humans re-typing between tabs.
- Runbook automation
- Converting a written procedure into an executable script, so the 3 am response is one command instead of one stressed engineer.
- Dashboard
- One screen answering "is everything okay?" from live data — the difference between knowing and assuming.
- Handover
- The deliverable that makes automation yours: repository access, documentation, and a walkthrough — the anti-lock-in clause.
ranjan@ranjan.info:~$ ls ../related
Related services
Engagements that commonly pair with this one.
Managed Server Administration
24×7 monitoring, patching, backups, and incident response on a flat monthly retainer.
View serviceHosting Control Panel Services
Migration, repair, optimization, and WHMCS automation for panel-based infrastructure.
View serviceInfrastructure Audit
Security, performance, cost, and disaster recovery — one honest report.
View serviceranjan@ranjan.info:~$ ssh [email protected]
Ready when you are
One paragraph is enough: your stack, the symptom, and when you need it solved. Emergencies are answered first.