Access changes are staged
Before changing SSH or firewall rules, the playbook asks for provider console access, a second terminal and a still-open current session. The new path is tested before the old one is removed.
Back to projects
Infrastructure / operations / security
A server baseline you can reason about.
A reproducible Ubuntu LTS baseline for turning a fresh server into a hardened, Docker-ready Golden Server with explicit validation and recovery paths.
GOLDEN SERVER
01UpdatedKnown package and reboot state
02HardenedNamed access and explicit exposure
03Docker-readyValidated before applications arrive
What it is
From a fresh host to a known state.
The Linux Server Playbook records my personal engineering standard for preparing a new Ubuntu LTS server before any application is deployed on it.
It keeps the decisions, safe execution order, validation evidence and recovery paths together. The goal is not to hide server operations behind a script; it is to make the system reviewable enough that a future automation still preserves the reasoning behind it.
The sequence
Security is also an order of operations.
An SSH port change affects the host firewall, the provider firewall, Fail2Ban, the client configuration and the validation plan. The chapters are arranged as one controlled build rather than a list of unrelated commands.
01Server preparation
Start from a known Ubuntu LTS image and record the initial state.
02Provider notes
Keep provider controls and recovery access in the plan from the beginning.
03User management
Create the named administrator and establish key-only access.
04SSH hardening
Change the remote-access posture while keeping a verified path open.
05UFW firewall
Use deny-by-default ingress and expose only the services that are intentional.
06Docker
Install Docker through a reviewable path and verify the resulting runtime.
07Fail2Ban
Add a second layer of protection for services that remain reachable.
08DNS
Connect the host to its forward and reverse naming expectations.
09Validation
Collect evidence for the effective state, not just successful commands.
10Troubleshooting
Keep recovery paths and inspection steps available when access is uncertain.
Operational discipline
Useful when the server is still empty.
The value is in the decisions around the commands: what must remain reachable, what needs evidence and where recovery lives if a remote change goes wrong.
Evidence proves the state
The final checklist retains the effective SSH configuration, listening sockets, firewall rules, Docker test result, Fail2Ban state and DNS answers. A command exiting successfully is not enough.
Manual by design
This is an explicit operational standard, not a one-click installer. Once the behaviour is stable, the same decisions can be encoded in cloud-init, Ansible or an image pipeline.
Scope and source
A baseline, not an application deployment guide.
The playbook intentionally stops before reverse proxies, databases, observability stacks, project secrets and application-specific configuration. Those belong to the project deployed on top of the server.