They should use a script or runbook that detects the environment, chooses the correct web server user, and applies the right edition-specific commands. That approach reduces manual variation and helps keep maintenance safe across Docker and package-based installations.
How to make maintenance repeatable across deployments
The core problem is not the maintenance task itself, but the variation between deployment types, package layouts, and service users. A safe process starts by detecting what is actually installed, then branching into the right command path instead of forcing one universal command set.
That matters because a script that assumes the wrong filesystem layout or service account can break the application, fail to reload the right service, or leave maintenance partially applied. The goal is consistency in outcome, not identical commands.
For teams that maintain multiple environments, the practical standard is to encapsulate the differences in a runbook or automation script, then keep the rest of the maintenance steps identical. That reduces operator guesswork and makes the process easier to review, test, and repeat.
What environment detection needs to decide
Environment detection should answer a small set of operational questions before any maintenance action runs: is this a containerised deployment or a package-based install, which web server is in front of the application, and which local account is expected to own the relevant files or commands. If those answers are wrong, the script may still run, but it will run in the wrong place.
The safest pattern is to make the detection explicit and conservative. If the script cannot identify the deployment with confidence, it should stop and ask for manual confirmation rather than guessing. That is especially important when the same host patterns may exist in staging and production.
For maintenance that touches files, caches, or service restarts, the script should resolve the correct service user and command path from the detected environment, then apply edition-specific steps only after the environment check passes. That keeps the branching logic close to the environment facts, not buried inside opaque shell commands.
Why edition-specific commands belong in the runbook
Passbolt maintenance is safest when edition differences are treated as a first-class part of the procedure. A command that works for one packaging model can be wrong for another, even if the application name is the same. The runbook should therefore name the edition-specific commands clearly and keep them separate from the shared steps.
This also makes testing much easier. Teams can validate the script against each supported deployment path, confirm the maintenance actions complete cleanly, and check that post-maintenance verification uses the same environment-specific assumptions. When the commands are written down and versioned, operators are less likely to improvise under pressure.
In practice, the best runbooks combine a short decision tree with explicit commands for each supported deployment type. That approach is more maintainable than a single overloaded script that tries to infer too much from the host.
Risk and Threat Considerations
Maintenance scripts become risky when they assume the wrong deployment context or execute privileged commands against the wrong service account. In mixed environments, that can lead to failed updates, partial restarts, permission errors, or unintended changes to the wrong instance.
Failure mechanism: A script that does not reliably detect the environment may choose the wrong command path, target the wrong web server user, or apply package-based steps to a container deployment. That breaks the maintenance flow and can leave the application in an inconsistent state.
Impact: The immediate effect is usually operational instability, but the broader risk is loss of maintenance reliability across environments. If operators cannot trust the procedure, they fall back to manual variation, which increases the chance of outage and configuration drift.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | Maintenance across deployments depends on repeatable, verified operational changes. |
| Recommendation — Standardize maintenance procedures and verify changes across every deployment type. | ||
| ISO/IEC 27001:2022 | A.8.9 — Configuration management | Different deployment paths require controlled, repeatable configuration changes. |
| Recommendation — Document and control deployment-specific maintenance steps before applying them. | ||
| NIST SP 800-53 Rev 5 | CM-3 — Configuration Change Control | The question is about safely applying maintenance changes across environments. |
| Recommendation — Approve and test maintenance changes before deploying them to each installation type. | ||
Practitioner Guidance
What to verify: Confirm that the script distinguishes deployment type before any destructive or privileged action, and test it against every supported install pattern you run in production. The check should be explicit enough that an operator can tell, from the logs, why one branch was chosen over another.
What good looks like: A single maintenance procedure that handles Docker and package-based installs without manual edits, while still making the environment decision visible and reviewable. The maintenance step should fail closed when the deployment cannot be identified cleanly.
Practitioner takeaway: The safest maintenance process is the one that treats deployment detection as part of the control, not as a convenience feature; once the environment is identified correctly, the rest of the work can be standardised.