Pro-bono practice · Modern ops for mission-driven orgs

Production that shows up when the need does.

Modern operations, sized for organizations that run on volunteers and donations.

Most mission-driven teams rent their systems: donated software seats and free vendor tiers they don't own and can't leave. We help you move to infrastructure you own outright.

  • The same free tiers, in your own accounts.
  • Set up as code you can copy.
  • Firing us is a runbook, not a migration.

No invoice for nonprofits and volunteer-run orgs. Call when you need to, if you need to.

Get in touch→See what we build
~/lentago/runbook.md
build it · break it · operate it
◆Offerings

What we build. Where to check.

Four things we deliver into estates you own, because we practice what we publish. Every offering links to a public repo you can read today: three you can fork and run now, and the fourth is being built in the open, issues and all. Nothing here is a slide.

01 / PUBLIC RECORD

A public record your community can trust

Your minutes, bylaws, notices, and policies kept as plain files in a repository your organization owns, with the rules about what must be posted and when kept right next to them. Merge a change and the records publish, a public "Is it posted?" board updates, and an Ask box that answers only from those records picks up the new facts. Being built in the open now — the plan, the decisions, and the work are all public.

Markdown vaultobligations-as-codegrounded Askin build
Receiptlentago/uvularia ↗
02 / PLATFORM

Cloud you own, not rent

A complete AWS environment written entirely as code: private networking, containers behind a load balancer, a managed database, a firewall, budgets and alarms. Every change is reviewed before it's applied, and no long-lived cloud passwords exist anywhere. It's AWS run the way it should be, in an account you hold the keys to — and because it costs real money, the runbook also tells you how to turn it off.

TerraformECS FargateRDSOIDC
Receiptlentago/solidago ↗
03 / OBSERVABILITY

See your systems on a free tier

Dashboards and alerts for everything you run, on Grafana Cloud's free tier. One small collector per machine, dashboards kept as files you can review before they change, and the free tier's limits treated as real constraints to plan around — not something to buy past.

Grafana CloudAlloyTerraform
Receiptlentago/drosera ↗
04 / ENABLEMENT

We show your people how to run it

The guide, in two volumes. Vol. 1 walks through how our own estate works, with labs you can run against it for free, starting with nothing but a browser. Vol. 2 gets a product into your accounts and running from an ops vault you own. Ownership is only real if your people can operate it.

GuideLabsOps vault
Receiptlentago/asclepias ↗
◆The pledge

We will never host your systems for you.

You'll own every piece. We'll show your people how to run it. Firing us is a runbook — a fork, not a migration off a service we run.

An anti-lock-in practice is only believable if walking away is trivial. So the boundary isn't a promise — it's the standing delivery model, true by construction.

01

Client-owned repos

Every kit ships as a repository you own from day one — a template plus an engagement, in open formats. Not a tenancy on ours.

02

Runs in your accounts

Anything that runs continuously runs in your accounts on free tiers — your GitHub Actions, your static host, your Grafana free tier. We don't host it.

03

No multi-tenancy

We never operate one system serving many organizations. No shared endpoints, no pooled data, no custody of your records.

04

Fireable from day one

Ongoing help is help with your systems, never a subscription to ours. A hand-off runbook stands from day one; if we stop tomorrow, you keep a working system.

05

Forkable is the exit

Reusable logic is open source. Every kit names what it depends on — GitHub and Actions included — and how to leave each one.

Adoption guideEverything is public and documented. Start here. ↗ReceiptADR-0007 · client-owned delivery, no multi-tenant SaaS ↗
◆The suite · ~/lentago/

Named systems. Honest parts.

Five systems run our own shop, and every one is free to take. Each is built so the parts specific to us swap out for yours. Where a system stands on someone else's platform, the Runs on column names it. The codenames are New England native plants.

01 · solidago
goldenrod — "to make whole"
lentago/solidago ↗

Cloud platform

Our AWS setup, written entirely as code: network, servers, database, web firewall, and encryption keys. Every change is proposed, reviewed, and applied automatically once it's approved, and nothing stores a long-lived password. It's what serves this site.

Runs on
AWSTerraformGitHub Actions
live since 2026-06 · serves lentago.dev
02 · kalmia
mountain laurel
lentago/kalmia ↗

Machine setup

Turns a freshly installed Linux computer into a fully set-up work machine with one command. Running it again is always safe: it only fixes what's out of place. Five ready-made profiles cover different kinds of machines.

Runs on
AnsibleDebian / UbuntuFedora
today: work machines → next: virtual machines and containers
03 · drosera
sundew
lentago/drosera ↗

Monitoring

Shows what your systems are doing right now, on dashboards anyone can read. One small collector on each machine sends in the numbers and logs. Every dashboard is saved as code and published on approval, so nobody's hand edit gets lost or drifts. If it isn't in the repo, it doesn't exist.

Runs on
Grafana CloudGrafana AlloyTerraform
first: our own machines, then our AWS account → next: one view across several setups
04 · betula
birch — where the logs keep
lentago/betula ↗

Log capture & archive

Keeps a complete, searchable record of what happens on a network: every domain looked up, every connection, every encrypted session opened. Each source sends its records wherever suits it: our firewall's go to Grafana's free tier, searchable at $0 a month, and our AWS account's go to Axiom.

Runs on
Fluent BitGrafana LokiAxiom
first source: our Firewalla → next: AWS's record of who changed what (CloudTrail)
05 · claytonia
spring beauty — a.k.a. the bullpen
lentago/claytonia ↗

AI coding agents

A small pool of AI coding assistants that work unattended on our own hardware. Drop a job in a shared folder, and a free worker picks it up, does the work on a fresh copy of the code, and proposes the change for review. It can't approve its own work; a person always decides. Today's workers run Claude Code, but any assistant could take the jobs.

Runs on
Claude CodeProxmoxGitHub
today: Claude Code → next: any AI coding tool
▲built to swap: replace any piece with your own without touching the rest. betula keeps the record; drosera shows what's happening now.
◆Custom help

When the work isn't a kit.

Not everything is a template. Custom work — audits, migrations, incident response, hardening — sized to your constraints and delivered into your estate under the same pledge. Free for nonprofits and volunteer-run organizations; everyone else, ask. Never a subscription to something we run.

AUDIT

Cost & posture audits

Find the NAT gateway eating the budget; the IAM role nobody owns; the bucket with forgotten logs. One-page report, no theatre.

MIGRATION

Cloud & datacenter migrations

Bare metal through cloud-native, and the platform shifts in between — moved without losing the rigor or a customer-visible outage.

ONCALL

Incident response & on-call

Runbooks, alarms, and on-call rotations humans can live with. Service targets that reflect reality, not aspiration. Pager hygiene included.

CI/CD

CI/CD & supply-chain hardening

Deploy pipelines with no stored passwords, every change reviewed before it applies, and signed builds — so a compromised pipeline can only reach what it was allowed to.

Receiptincident register · post-mortems, published verbatim ↗Send the symptoms →
◆Operating principles

How we think about production.

The full runbook is longer, drier, and in the repo. These are the six we'd bring into a room on day one.

01

Build it, break it, operate it.

The person who designs the system is the person who carries the pager for it. Otherwise the design is a suggestion, not a commitment.

02

Blast radius over blast capacity.

Least-privilege isn't a checkbox — it's the default. If a compromised pipeline can reach production, the problem is the pipeline, not the compromise.

03

Runbooks beat heroics.

An incident handled by a sleepy engineer following the runbook is better than a hero who remembers. Write the doc. Update it when it lies.

04

Observable from day one.

You cannot operate what you cannot see. Logs, metrics, traces, and a single dashboard a human actually opens. No 'we'll add it later.'

05

Plan on PR. Apply on merge.

Infrastructure changes are code review. OIDC, no long-lived credentials, signed artifacts. The pipeline is the contract.

06

Cost is a posture.

A NAT gateway you forgot about is a security problem. A forgotten log bucket is a compliance problem. Run the audit monthly, not yearly.

◆About

Nearly thirty years carrying the pager.

I've kept production running around the clock since 1997: first in server rooms where every change had physical consequences, now in cloud systems defined entirely in code. These days I help organizations that run on donations run that same kind of reliable setup on infrastructure they own, and I do it in the open.

Based: New England, US
Working: remote · async-friendly
Taking new work: Q4 2026 forward
2022 —

Moving the discipline; keeping the rigor

Moved to cloud-native work: infrastructure written as code, every change reviewed where the whole team can see it. The tools changed; the habits didn't. Rehearse the failure, write down the fix, make the next change boring. Lentago is where I practice those habits in the open, on an estate anyone can copy.

2017 — 2021

Internet engineering; public cloud

A much larger company bought us and put real money behind the platform. I ran disaster-recovery drills, cut recovery times, and made every component within reach redundant. Led the capacity buildout team, with a lot of vendor evaluation along the way. The job grew to cover internet routing, large email domains, DNS, CDNs, and cloud integrations.

2007 — 2016

Operator number three at a startup; IPO five years later

Joined a small startup of fewer than 50 people in 2007 as its third infrastructure operator. Each instance of the platform was hardware we designed and racked ourselves: load balancers, storage, layers of network switching, one cabinet at first and later several. I made the buildouts repeatable and added redundancy wherever it would fit. Every hardware generation changed something, so I used configuration management and orchestration to keep those differences away from the support team.

1997 — 2006

Graveyard shift to principal; left it better than I found it

Started as the overnight operator: data-center keys, orders to change the backup tapes, and escalations from support. I learned AIX and VMS from the career sysadmins I'd just woken for the third time that night, and never called anyone about the same thing twice. I earned the day shift by doing a full sysadmin's job on nights, trained my own replacement, and kept leading the night shift from days. By 2005 I was a principal operator who'd brought two new data centers from construction to production.

◆Contact · POST /consult

Queue's open.

No invoice if you're a nonprofit, a volunteer-run org, or the one person keeping the lights on somewhere. If you know what you need, send the repo. If you don't, send the symptoms. Either way you'll hear back inside a day.

Signalavailable on request
Response< 24h on weekdays
~/consult.sh