Sites do not stay healthy by themselves. This topic covers the work that keeps them that way: the automation around every change (DevOps) and the steady, unglamorous care of a running system (sysadmin). Both are habits, and habits are easier to keep when they are written down and partly automated.
Two halves of the same job
The two labels are often used as one, but they answer different questions:
- DevOps is about change: how a commit becomes a deployment, how environments stay consistent, how a rollback happens at 23:00 without heroics.
- Sysadmin is about the steady state: is the site up, are the backups restorable, are certificates renewed, is access still appropriate, has anything quietly drifted?
A project that nails automation but ignores the steady state ends up with a beautiful pipeline nobody monitors. A project that nails maintenance but deploys by hand ends up with a fragile release day. We plan for both from the first week — even on small projects, with small versions of each.
Everything as code
If a setting exists only in someone’s browser session, it is a liability. So we push configuration into the repository wherever it can live there:
- Infrastructure and hosting config in version control, reviewed like any other change.
- DNS, redirects, headers, and cache rules declared in the project, so the “how is this configured?” question has an answer that can be diffed.
- Secrets stay out of the repository and live in the platform’s secret store, scoped per environment, rotated when someone leaves a project.
- Nothing important only in a dashboard. A dashboard is fine for a quick look, not as the single copy of a production setting.
The payoff is not elegance, it is recoverability: a site whose configuration lives in Git can be rebuilt from scratch, and the rebuild is a routine job instead of an archaeology project.
Environments that behave the same way
Most “works locally, breaks in production” stories come from environments that quietly differ. Our rule is to keep the differences few, known, and documented:
- Same build process everywhere, so a local build and a production build produce the same thing.
- Preview environments per branch, so reviewing a change is a URL, not a meeting.
- Production data stays in production. Real customer data does not belong on a laptop; test data is generated or anonymised.
- Failures are visible in development too, so error reporting and logging are exercised long before launch day.
Maintenance on a schedule
Running a site without a maintenance rhythm means finding out about problems from someone else. We keep a short, boring calendar:
Daily and weekly
Uptime and error checks, review of failed builds, a glance at logs for anything new and repeated. Most issues are cheap at this stage and expensive three weeks later.
Monthly
Dependency and security patches, backup restore test on a sample, certificate and domain expiry review, check that alerts still reach a human.
Quarterly
Access review (who still needs what), cost review, documentation refresh for the parts that changed, and a walk through the runbook to see whether it still matches reality.
Access and accountability
Access control is the part of ops that is easiest to skip until it is the reason for an incident. What we insist on:
- Least privilege, per person. Shared logins destroy accountability and make offboarding a guess. Every person gets their own account with only what their role needs.
- Two-factor everywhere, especially for DNS, hosting, repository, and email — the four accounts that can take a site down or leak it.
- A short list of who can deploy and who can change DNS, reviewed quarterly.
- An audit trail. Deploys, rule changes, and access grants are logged somewhere we can read later, because “who changed this?” should never be a mystery.
- Offboarding as a checklist, not a memory test: keys revoked, sessions killed, secrets rotated, accounts removed.
When things break
Every project gets a runbook, and every incident gets a short note. The runbook covers the first ten minutes; the note covers the next week:
- First checks in order: is it DNS, TLS, the deployment, a third party, or the visitor’s network? A short ordered list beats a long speculative one.
- Who to tell, and how. A single place where updates are posted, so nobody asks five people for status.
- How to roll back, written before it is needed, tested once in calm weather.
- A blameless review afterwards: what happened, what we believed at the time, what made it hard to see, and the one change that would prevent it. The output is a small fix, not a document nobody reads.
- A follow-up on the fix. An action item without an owner and a date is a wish.
Good ops work looks like nothing happening. The measurable signs are boring: few hand-made changes, alerts that reach a person, restores that work, and a team that knows what to do at 02:00 without waking up a specific hero.
What we publish under DevOps & Sysadmin
Articles in this topic go into the practical details: writing a deploy pipeline you can trust, keeping environments consistent, structuring backups and restore drills, rotating secrets, monitoring a static site properly, and the smaller craft of runbooks and incident notes.
Related reading: how we host the sites we build, and the code standards behind them.
Running a site that has grown beyond one person’s memory? Tell us what keeps breaking and we will start with the shortest list that removes the most risk.