Guarded Disk Cleanup Maintenance over SSH

Free disk space on remote Linux servers without giving everyone root and a shell. This blueprint SSHes into a target host, measures disk usage, pauses for human approval when the host looks production-like, then removes week-old temp files, prunes unused Docker images, and force-rotates logs. A hard allowlist stops anyone from pointing it at an arbitrary machine, results are posted to Slack, and each targeted host is tracked as a Kestra Asset so you can see which servers were cleaned and when.

How it works

1. The validate_host task (io.kestra.plugin.core.execution.Fail with runIf) rejects any target_host that is not in the allowed_hosts variable and does not match the svp- naming prefix.
2. The pre_cleanup_metrics task (io.kestra.plugin.fs.ssh.Command) records the root filesystem usage percentage before any change.
3. The wait_for_approval task (io.kestra.plugin.core.flow.Pause) only activates when the host name contains srv-app and force_cleanup is false, so production-like machines require an explicit resume while dev boxes flow straight through.
4. The run_cleanup task executes sudo find /tmp -type f -atime +7 -delete, sudo docker image prune -af --filter "until=168h", and sudo logrotate -f /etc/logrotate.conf. Its assets block registers the host as a io.kestra.plugin.ee.assets.VM asset with operation: disk_cleanup metadata.
5. The post_cleanup_metrics task captures used and free space after cleanup, and notify_slack posts the report; a flow-level errors handler alerts on any failure.
6. A pluginDefaults block injects host, username, and privateKey into every io.kestra.plugin.fs.ssh task, so connection settings live in exactly one place.

What you get

• A guarded, repeatable alternative to ad hoc "ssh in and delete stuff" maintenance.
• Conditional human approval only where it matters (production naming patterns).
• Before/after disk metrics captured as execution artifacts.
• Slack notifications on success and failure, and asset-level tracking of cleaned hosts.

Who it's for

• SRE and IT operations teams handling recurring disk pressure alerts.
• Platform teams standardizing Day 2 maintenance with guardrails.
• Anyone who wants junior operators to run cleanups safely.

Why orchestrate this with Kestra

A cron script on each host cannot pause for approval, cannot centralize its allowlist, and leaves no shared record of what ran where. Kestra provides conditional runIf guardrails, a first-class Pause gate, pluginDefaults to avoid repeating connection details, centralized secrets for the SSH key, error handling with Slack alerts, and an asset catalog entry per maintained host.

Prerequisites

• SSH access from the Kestra worker to the target hosts with a user allowed to sudo.
• Docker and logrotate installed on the targets (or trim the commands).
• Kestra Enterprise Edition for the Assets tracking (remove the assets block to run on OSS).

Secrets

• SSH_PRIVATE_KEY: private key for the remote_user account on target hosts.
• SLACK_WEBHOOK_URL: Slack incoming webhook for maintenance reports and failure alerts.

Quick start

1. Add the secrets above to your Kestra namespace.
2. Edit allowed_hosts and the naming-prefix guardrail to match your fleet.
3. Execute against a staging host with force_cleanup: true to validate connectivity.
4. Run against a production-like host and resume the paused execution to approve.

How to extend

• Trigger from a disk usage alert webhook (Prometheus Alertmanager, Datadog) instead of manually.
• Compute freed space from the pre/post metrics and include it in the Slack report.
• Loop over multiple hosts with io.kestra.plugin.core.flow.ForEach.
• Add journal vacuuming (journalctl --vacuum-time=7d) or package cache cleanup steps.

Links

• SSH Command plugin docs: https://kestra.io/plugins/plugin-fs/ssh/io.kestra.plugin.fs.ssh.command
• Kestra Assets docs: https://kestra.io/docs/enterprise/governance/assets