Running production without a DevOps hire: a checklist for the first-time CTO
Ten things that must be true for a small team to run production without an ops engineer: deploys, rollback, HTTPS, backups, alerts, logs, access, secrets, updates and cron.
You are the CTO of a five-person startup. Nobody on the team is an ops engineer, and production is now your job on top of everything else.
This post is the list of things that actually need to be true for production to run without a DevOps hire. It is tool-agnostic: use it to check whatever setup you have today.
Disclosure: we build DollarDeploy, a control plane that deploys and operates apps on servers you own. Where it covers an item, we say so. Where it does not, we say that too.
Why it matters: code is maybe 40% of shipping software. The other 60% is servers, databases, HTTPS, access, backups and monitoring. Coding agents made the first part cheap. The second part still lands on one person, usually you.
The short version
If you only read the bold lines, this is the checklist:
- Every deploy comes from Git, never from a laptop.
- You can roll back in under a minute.
- HTTPS renews itself.
- Backups run on a schedule, and you have restored one.
- Someone gets told when the app is down.
- Logs are kept long enough to debug last week.
- Every person and every agent has only the access they need.
- Secrets live in one place, not in Slack.
- Security updates install themselves.
- Scheduled jobs are visible, not hidden in a crontab.
The rest of the post is what each one means, and the cheapest way to get there.
1. Every deploy comes from Git
The rule: production runs a commit that exists on the remote. Nobody runs scp or git pull on the server by hand.
Why: when something breaks, the first question is "what changed?". If deploys come from Git, the answer is a commit. If they come from someone's laptop, the answer is a guess.
How: connect the GitHub repo to whatever deploys your app and deploy on push to the main branch. In DollarDeploy that is the default: connect the repo, pick a server, and every push builds and deploys.
2. You can roll back in under a minute
The rule: going back to the last good version is one action, not a rebuild.
Why: most incidents in a small team are a bad deploy. The fastest fix is to put the previous build back, then debug calmly.
How: keep the previous builds and make redeploying one of them a button. DollarDeploy keeps a build history per app; press Deploy on any earlier build to ship it again without rebuilding.
Test it: do a rollback on a quiet afternoon, before you need one at 2 a.m.
3. HTTPS renews itself
The rule: certificates are issued and renewed automatically.
Why: an expired certificate takes the site down as surely as a crash, and it always happens on the day nobody remembers the renewal.
How: use Let's Encrypt with automatic renewal. DollarDeploy sets up HTTPS for every app and renews it. Its host inspection also flags certificates that are close to expiry.
4. Backups run on a schedule, and you have restored one
The rule: the database is backed up automatically, the backups are stored somewhere other than the same disk, and you have done one restore.
Why: a backup you have never restored is a hope, not a backup.
How:
- Schedule it. Daily is enough for most early products.
- Restore it once. Into a scratch database, and check the row counts.
- Write down the steps. One paragraph in the README is enough.
DollarDeploy has manual backups on every plan and scheduled backups on paid plans.
5. Someone gets told when the app is down
The rule: a failed health check reaches a person, not just a dashboard.
Why: small teams find out about outages from customers. That costs more trust than the outage itself.
How: pick one channel the team actually reads (email, Slack, Discord) and route alerts there. Agree who looks first on weekdays and weekends. For two to five people, a simple rota in a shared calendar is enough.
6. Logs are kept long enough to debug last week
The rule: you can read the logs from the day the bug happened, not only since the last restart.
Why: "it happened on Tuesday" is the most common bug report. If logs rotate away in a day, you are guessing.
How: keep at least a few weeks of app logs, searchable from a browser. DollarDeploy keeps 30 days of logs and monitoring on every plan.
7. Every person and every agent has only the access they need
The rule: nobody shares one admin login, and no coding agent holds raw cloud credentials.
Why: in a small team, access grows by accident. A contractor gets the root password "just for today". An agent gets a full API key because it was faster. Then someone leaves, or an agent makes a confident mistake.
How:
- Give roles, not passwords. A contractor who deploys one app does not need the server.
- Scope agent keys. Let agents read logs and deploy; keep deletes and new servers on manual approval.
- Hide secrets from agents unless they need to write them.
DollarDeploy has five roles (View, Deploy, Write, Maintain, Admin) per team, project, app or host. API keys and MCP connections for Claude, Cursor and other clients are scoped by role and project, and by default cannot read env values. AI actions that change something, like creating a server or deleting an app, can pause for you to approve.
8. Secrets live in one place
The rule: env vars and keys are stored in one system, with access control, and never pasted into chat.
Why: a secret in Slack is a secret in every laptop, phone and export of that workspace.
How: keep env vars in your deploy tool or a secrets manager, and rotate anything that was ever pasted into a chat. When someone leaves, rotate what they could read.
9. Security updates install themselves
The rule: the operating system patches itself, and you know when it needs a reboot.
Why: the servers of small teams get compromised through old packages, not clever attacks.
How: turn on unattended security upgrades and choose a reboot window. DollarDeploy enables automatic Linux security updates when it prepares a server, with automatic reboots off until you pick a time.
10. Scheduled jobs are visible
The rule: every cron job has an owner, logs and an alert when it fails.
Why: a crontab on one server is invisible. The nightly invoice job fails quietly for two weeks, and you learn about it from accounting.
How: run scheduled jobs from a system that records every run. DollarDeploy has cron jobs for apps and hosts on paid plans; each run is a task with logs and retries, and you get one notification when a job starts failing and one when it recovers.
Yes, but
You can do all of this yourself. A VPS, a CI pipeline, Let's Encrypt, a backup script, an uptime monitor and a password manager cover the list. Many teams run that way.
The cost is time. Each item is an afternoon to set up and a small, recurring job to keep working. For a first-time CTO the real risk is not the setup; it is that items 4, 5 and 10 quietly stop working while you are shipping features.
Our honest limit: DollarDeploy is run by a small team, and we do not publish an SLA or a status page yet. If you need contractual uptime guarantees today, factor that in.
The bottom line
Production without a DevOps hire is possible when these ten things are true and stay true. Check them once a quarter.
If you would rather not maintain the list yourself, DollarDeploy covers deploys from GitHub, rollback, HTTPS, logs and monitoring, backups, roles, scoped agent access and cron, on servers you own. Try it free, no card needed.