Cloud Security · June 2, 2026

A lockout-safe first hour for a new DigitalOcean droplet

The first hour of a server often sets the tone for the next year. A new droplet should not begin life as a collection of ad hoc shell commands copied from memory.

Good baseline hardening is not dramatic. It verifies SSH access, creates a non-root path, enables a host firewall deliberately, turns on unattended security updates, and leaves enough evidence for the next engineer to understand what changed.

The operational problem

The most common failure is not a sophisticated attack. It is a rushed SSH or firewall change that locks the team out, followed by undocumented recovery work. The second failure is treating cloud provider controls and server controls as the same thing. They are separate layers and should be checked separately.

The Mirogate baseline

• Run audits before applying changes, so the current state is visible.
• Keep hardening scripts dry-run by default and require an explicit apply flag.
• Allow SSH before enabling UFW and verify the active SSH port.
• Use DigitalOcean Cloud Firewalls as a platform-level control, not as a replacement for host configuration.
• Keep a recovery note with console access and rollback commands before touching SSH settings.

What we released

secure-droplet-bootstrap packages this approach as a Codex skill, a dry-run hardening script, a read-only audit script, and a checklist for DigitalOcean firewall setup.

APPLY=1 SSH_PORT=22 ADMIN_USER=deploy ./scripts/harden-ubuntu.sh
./scripts/audit-droplet.sh

This is a baseline, not a certificate. Use it to make first-hour setup repeatable, then adapt it to your risk model, hosting policy, and application needs.