Shipping software alone doesn’t have to feel like juggling chainsaws.

You don’t need a massive DevOps platform or a big-team process to ship reliably. What you do need is a tiny bit of structure: just enough to protect you from late-night emergencies, lost context, and “wait, how did I deploy this last time?” moments.

That structure can live in a single document: a one-page DevOps manual.

This post walks you through how to design that one page so that you — a solo dev or tiny team — can ship like a disciplined engineering org without drowning in process.

What Is a One-Page DevOps Manual?

Think of it as a pocket guide to running your app in production:

• How to deploy
• How to roll back
• How to handle incidents
• What must be true before you hit “deploy”
• The minimal rules that keep you from accidentally breaking production

It’s not meant to cover everything. It’s meant to:

• Be readable in 2–3 minutes
• Capture your core operational habits
• Replace ad-hoc decisions with repeatable steps

You can store it as ONE_PAGE_DEVOPS.md in your repo and update it as you learn.

Let’s break down the key building blocks.

1. Runbook Templates: Make Repeating Work Boring (In a Good Way)

As a solo dev, your biggest hidden cost is re-deciding how to do things you’ve already done: restarts, database migrations, cache flushes, log checks, and so on.

Runbooks turn that chaos into step-by-step, copy‑pasteable procedures.

A runbook is a short, structured doc that answers:

• What is this task?
• When should I run it?
• Exactly how do I do it?
• How do I confirm it worked?

You don’t need a separate file for every task. On your one-page manual, define a simple runbook template and keep 2–5 of your most common tasks there.

Example runbook template:

### Runbook: [Task Name]

**Purpose:** Why this task exists (1–2 sentences).

**When to run:** Triggers or situations.

**Pre-checks:**
- [ ] Any services to put in maintenance mode?
- [ ] Any backups to take first?

**Steps:**
1. Step 1
2. Step 2
3. Step 3

**Validation:**
- [ ] Logs look normal
- [ ] Health checks pass
- [ ] Key user flow works: [describe]

**Rollback plan:**
- [ ] How to undo or mitigate if something goes wrong

Populate a couple of these:

• “Deploy a new version”
• “Run database migrations”
• “Restart the app / worker service”

Now, whenever you perform the task, you follow the runbook and update it if you find a better way. Over time, even as a solo developer, your operations become consistent and predictable.

2. Incident Response Playbooks: Don’t Improvise During a Fire

When production is down, your brain is the least reliable tool you have.

That’s why teams create incident response playbooks: pre-written, step‑by‑step guides for the most likely outages. You should too — just in a stripped‑down, solo-friendly way.

Your one-page DevOps manual should have 1–3 incident playbooks for scenarios like:

• App is up but very slow
• API returning 5xx errors
• Database is overloaded or unreachable

Each playbook answers:

• First moves: What do I check before anything else?
• Triage path: What metrics/logs/tools do I look at in what order?
• Temporary mitigations: How to reduce impact quickly.
• When to roll back or disable features.

Example incident playbook: “API returning 5xx errors”

### Incident Playbook: API 5xx Spikes

**Symptoms:**
- Error rate > 5% for > 5 minutes
- Users report failures loading data

**First moves (in order):**
1. Check production logs for new error patterns.
2. Check last deployed version and deployment time.
3. If a deploy happened in last 30 minutes, prepare to roll back.

**Triage path:**
1. Check CPU/memory usage on app servers.
2. Check database connections and slow queries.
3. Check any third-party APIs for outage status.

**Fast mitigations:**
- If errors started right after a deploy: roll back to previous version.
- If DB is overloaded: temporarily disable non-critical background jobs.

**After incident:**
- Write 5–10 bullet points: what happened, what fixed it.
- Add any new steps or checks to this playbook.

The goal isn’t perfection. The goal is to avoid starting from zero thinking when you’re stressed.

3. DevOps Guardrails: Team-Level Safety With Solo-Level Simplicity

Solo developers often skip process because it feels heavy. But some minimal guardrails give you team-like safety with almost no overhead.

Your one-page manual should define these as hard rules, not “nice to haves.”

a) Protect the Main/Production Branch

Never treat your main branch like a scratch pad.

Set branch protection rules so that:

• No one (including you) can push directly to main or master.
• Changes must go through pull requests (PRs).

Why this matters even when you’re alone:

• Forces you to pause and review your own work.
• Prevents accidental git push from sending half-baked changes to production.

Even a self-reviewed PR is far better than merging from a random local state.

b) Require Passing Builds (and Tests) Before Merge

Your protected branch should only accept code that passes CI.

Configure your repository so that before merging a PR into main:

• CI must run a build
• Ideally, unit tests or at least smoke tests must pass

This gives you:

• A minimum quality bar for every change
• Early detection of broken builds before they hit production

It’s not big-team bureaucracy — it’s a tiny automation that saves you from future pain.

c) Use PRs as a Solo Review Tool

Even if you’re the only person in the repo, PRs can still work for you:

• Write a quick PR description: what changed, why, and any risks.
• Skim the diff once as if you were someone else.
• Only then hit merge.

That 30-second mental reset often catches obvious mistakes.

4. The Pre-Deployment Checklist: Your Last Line of Defense

Humans are bad at remembering everything, especially under time pressure.

A pre-deployment checklist is a short list of must-do steps before every release. It lives in your one-page manual and should be reused for every production change.

Example pre-deployment checklist:

### Pre-Deployment Checklist

- [ ] All tests passing in CI
- [ ] PR description clearly states changes and risks
- [ ] Database migrations reviewed and tested locally
- [ ] Feature flags prepared (if used) for risky changes
- [ ] Rollback plan written (how to revert this change)
- [ ] Monitoring dashboards checked (baseline looks normal)
- [ ] Change log or release notes updated

Customize this to your stack, but keep it short enough that you’ll actually use it.

This checklist:

• Catches missed steps (like forgetting a migration or breaking a cron job)
• Makes releases consistent month after month
• Reduces anxiety because you know you did your homework

Over time, when something goes wrong, you ask: “Should we add a step to the checklist?” That’s how you get better without adding heavy ceremony.

5. Treat Your Solo Setup Like a Mini Team Environment

The underlying mindset shift is simple:

Stop treating your solo environment as “just me” and start treating it as a tiny team with almost no people and lots of automation.

Let templates, automation, and policies do what headcount usually does in bigger orgs:

• Runbooks replace tribal knowledge
• Incident playbooks replace war rooms
• Branch protection and PRs replace peer pressure
• CI checks replace “it works on my machine”
• Pre-deployment checklists replace memory and heroics

Your one-page manual stitches all of this together in one place. When something breaks or you onboard a collaborator later, this document becomes a single source of operational truth.

Putting It All Together: A Simple One-Page Layout

Here’s a sample outline for your ONE_PAGE_DEVOPS.md:

# One-Page DevOps Manual

## 1. Guardrails
- Protected branches: main
- No direct pushes to main; PRs only
- CI must pass before merge

## 2. Pre-Deployment Checklist
[Your checklist here]

## 3. Runbooks
- Deploy a new version
- Run DB migrations
- Restart app/worker

## 4. Incident Playbooks
- API 5xx spikes
- App slow / high latency

## 5. Notes & Improvements
- Add ideas, lessons learned, and future improvements here.

That’s all you need to start.

Keep it short. Keep it visible. Update it whenever reality teaches you something the hard way.

Conclusion: Ship Like a Team, Even If You Are the Team

You don’t need enterprise tools to be disciplined. You need:

• A simple, living one-page manual
• A few guardrails that stop the most common mistakes
• Runbooks and playbooks that keep you calm in routine tasks and crises
• A pre-deployment checklist that turns every release into a repeatable ritual

Do this, and you turn your solo setup from “hero-driven” to system-driven. You’ll ship more confidently, break production less often, and when things do go wrong, you’ll have a plan written by a calmer version of yourself.

Start with one page. Refine it with every deploy and every incident. Over time, that single document will become the quiet teammate that helps you ship like a team — even when you’re the only one in the room.