How a Linux Infrastructure Engagement Starts and Grows
A deliberate progression from first contact to steady operations, and eventual transition. Nothing is implicit. Responsibility moves in steps.
The long-term effect is less noise, fewer surprises, and calmer days.
Last reviewed: March 2026
Why this exists
The engagement lifecycle explains how work with Permalink progresses over time. It exists to make expectations explicit. What happens when. Who is responsible. Where responsibility ends. Making these phases explicit reduces surprises, misaligned assumptions, and the risk that comes from unclear ownership.
This model is designed for organizations that value predictability, documentation, and clear responsibility over reactive or ad-hoc intervention.
What gets quieter over time
This is not immediate. It accumulates slowly. The result is less background tension, fewer mental checklists, and fewer situations demanding attention at the wrong time.
- You stop carrying a private list of things that might break.
- Responsibility becomes explicit instead of assumed.
- 3AM situations become rare and more contained when they occur.
- Time away no longer requires contingency planning in your head.
- You are no longer the single point of memory for the system.
- Incidents stop escalating emotionally before they escalate technically.
- Decisions no longer depend on undocumented history.
- The infrastructure becomes boring enough to ignore most days.
- Calm becomes the baseline, not a temporary state.
Inherited infrastructure
Many engagements begin with systems that were designed, built, or operated by others. These environments often carry undocumented assumptions, historical shortcuts, and unclear ownership.
Existing infrastructure is never taken over informally or by assumption. Before any operational responsibility is accepted, systems pass through a deliberate assessment and onboarding phase.
This phase focuses on understanding, not optimization. Access boundaries, system behavior, data paths, backup coverage, and recovery options are examined and documented as they actually exist.
During this phase, no operational responsibility is implied. Findings, risks, and limitations are documented explicitly before stewardship begins.
If the assessed risk, complexity, or condition of the systems exceeds what can be responsibly stewarded, the engagement may stop at this stage.
The seven phases
The engagement progresses from initial contact through audit & discovery, scope & pricing definition, technical onboarding, to daily management. Each phase is explicit and documented, with clearly defined responsibility.
- (1)First Contact
Email with a brief description of systems and current concerns. Decide whether working together makes sense, for both sides.
- (2)Audit & Discovery
Paid assessment to understand systems, dependencies, and operational reality. Outcome: clear insight into risks and unknowns.
- (3)Scope & Pricing
Boundaries, expectations, and pricing defined based on real risk. Either party may decide not to proceed.
- (4)Technical Onboarding
Documented access, monitoring integration, backup verification, and baseline operational setup. Operational responsibility begins here.
- (5)Daily Management
Monitoring, backups, incident handling, and other agreed elements of ongoing operational management.
- (6)Reviews & Adjustments
Periodic assessment of scope, monitoring, backups, and operational effectiveness. Confirm scope still fits reality and risk has not drifted.
- (7)Leaving Cleanly
Finalized documentation, access removal, handover of responsibility. Offboarding details →
Security, at the start
A point-in-time security baseline may be established during onboarding. Targeted configuration review, exposure assessment, and limited vulnerability scanning. Continuous intrusion detection is not included by default.
Next steps
A short email describing your systems and current situation is enough to begin. From there, we can determine whether long-term operations make sense.