Operational Stewardship
Long-term responsibility for the operation, maintenance, and evolution of defined Linux and Unix-like infrastructure.
- Engagement modelretainer
- Ownershipsingle accountable operator
- Cadencecalm, documented
Permalink, calm Linux stewardship
Long-term Linux infrastructure operations,
Long-term Linux infrastructure operations,
designed to avoid improvisation at 3AM.
I help people running serious Linux and Unix-like infrastructure keep their systems stable, carefully maintained, and understandable over time.
whoami
independent linux systems administrator, strasbourg, france.
cat ./scope
retainer-based operational stewardship · infrastructure design (fixed-price, scoped) · emergency support (rare, short-term)
cat ./stack
Debian/Ubuntu · KVM · Nginx · PHP · MariaDB · Postfix/Dovecot · WireGuard
What this is
I work directly with a small number of clients at a time, taking operational responsibility for defined parts of their Linux and Unix-like infrastructure, from day-to-day server management to long-term reliability planning. This ranges from single dedicated servers to multi-service stacks: SaaS platforms, internal APIs and tooling, business systems, and self-hosted environments.
The goal is steady, documented operations with clear accountability. No ticket queues. No MSP contracts. No availability theater.
How services are structured
Most engagements are built around long-term Operational Stewardship, providing ongoing oversight and daily management of existing systems. Infrastructure Design is an upstream service for new environments built from scratch; it often transitions naturally into stewardship, covering a different stage of an infrastructure’s lifecycle.
Infrastructure Design
Designing new infrastructure from scratch, tailored for reliability, security, and long-term operability.
- Engagement modeltime-bounded
- Deliverablesarch., docs, handover
- Transitions tostewardship (often)
Emergency support
Short-term stabilization for rare, critical incidents outside an existing engagement. Not a default mode of working; engagements are built to make it unnecessary.
Learn moreHow engagements are handled
Scope, boundaries, and lifecycle
All work begins with a structured onboarding process to make sure changes are safe and predictable. This also ensures smooth offboarding and handover if needed.
Responsibility & continuity
You work directly with a single accountable operator. There is no team handoff, rotating staff, or loss of context. Only continuity and accountability.
All engagements are structured so that systems, documentation, credentials, and operational knowledge remain client-owned and accessible.
Continuity is achieved through documentation, clear boundaries, and deliberate onboarding and clean transfer if required, not through personal availability or undocumented knowledge.
When this typically fits
Different environments need different kinds of operational support. The goal here is calm, reliable systems that continue working quietly over time. If that approach resonates with you, we will probably work well together.
- You run production Linux infrastructure without a dedicated operator.
- Systems grew organically; documentation is incomplete.
- You want to understand your infrastructure six months from now.
- You plan for failures instead of hoping they won’t happen.
- You require 24/7 on-call coverage or SLA-backed guarantees.
- Infrastructure is expected to change every week.
- Teams prefer ticket queues over clear operational ownership.
- Emergency response is expected to be the default mode.
Contact
A short message describing your situation or planned project is enough to begin. I’ll follow up with next steps and a structured approach to your infrastructure needs.
Pricing details are on the Pricing page.