The agency's problem
An agency that hosts or administers client servers inherits a mixed set: different providers, different ages, different ways of starting the app and different levels of documentation. Time goes on the tenth server that behaves differently from the first nine. The risks are also shared: if a client key leaks from an agency laptop, the agency is the one explaining it. Fixed jobs with written acceptance checks fit because the agency can pass the evidence to the client and keep its own staff for design and support.
- Mixed providers and generations of server.
- Credentials that sit on staff machines.
- No time for the slow, careful chores.
Which jobs suit which client situations
The monthly patch and review suits a client with one production server that nobody owns. The Terraform drift review suits a client whose cloud account is managed by code and also changed in the console. The Kubernetes repair suits a client whose single Deployment will not roll out. The secrets job suits a client whose app reads an env file. The move project suits a client leaving a retired server. In each case the buyer is the client or the agency on the client's behalf, and the work is scoped to one server, one configuration or one Deployment.
- One server, one configuration, one Deployment per job.
- Evidence packs the agency can forward to the client.
- Prices are published test prices, quoted per scope.
Keeping credentials with the client
The jobs are designed so the client holds production credentials. We work from exports, copies and read-only routes that the client creates and revokes, and hand over change sets to apply, or use a time-limited account for a named step. The server or account owner must authorise the work in writing, and every access route is created and revoked by that owner, not by the agency on their behalf. Terraform plan files and state can contain sensitive values, and Kubernetes Secrets are unencrypted by default, so the jobs treat these as sensitive artefacts and keep them out of notes.
- Read-only routes created and revoked by the client.
- Plan output and secrets are not kept after acceptance.
- The server or account owner authorises the work in writing; the agency may make the enquiry for them.
What to ask for in the first message
Send the provider, the operating system or tool version, a description of the stack and what is going wrong, with every secret removed. Say who approves changes. Do not send logins, keys, state files or customer data. These services are new, with no delivery history, so expect scope and checks to be agreed in writing before anything starts, and expect payment to follow the agreed checks and sign-off.
- Scope before access.
- Written acceptance checks.
- No credentials by email.
Sources and limits
- Terraform: sensitive data in state Checked 2026-10-11.
- State and plan files can hold sensitive data and should be stored remotely, encrypted and access-controlled.
- Kubernetes: Secrets Checked 2026-10-11.
- Secrets are unencrypted in the data store by default and anyone able to create pods in a namespace can read its Secrets.