An Ubuntu production server needs a repeatable baseline. The exact packages depend on the workload, but identity, patching, network exposure, service supervision, backups and telemetry are universal. Document the baseline as code or a runbook so the next server is not configured from memory.
Start with ownership and inventory
Record provider, region, purpose, owner, operating-system version, public addresses, domains and renewal dates. Define what data the host may process and where it may be stored. Keep a dependency inventory and use only properly licensed software and authorized data sources.
Harden administrative access
Create named administrator accounts, use SSH keys and disable direct root login and password authentication after verifying key access. Restrict sudo, protect private keys and require multi-factor authentication at the hosting provider. Keep a documented emergency-access path and test it without weakening normal controls.
Patch and reduce exposure
Install supported Ubuntu releases, apply security updates and decide whether automatic updates fit the workload. Remove unused packages and listen only on required interfaces. Configure a deny-by-default firewall, expose application ports through the intended reverse proxy and keep databases private. Rate limiting complements authentication; it does not replace it.
Run services predictably
Use systemd or an appropriate process manager with a dedicated unprivileged user, explicit environment, restart limits, startup ordering and resource constraints. Do not store secrets in the repository or command history. Validate configuration before reload and keep deployment artifacts versioned so rollback is fast.
Backups and recovery
Back up databases, user uploads and irreplaceable configuration to separate storage. Encrypt backups, define retention and monitor completion. A successful backup log is not proof of recovery: restore into an isolated environment regularly and measure recovery time and acceptable data loss.
Logs, metrics and alerts
Collect disk, memory, CPU, load, network, service state, certificate expiry, HTTP errors and application health. Centralize important logs with access controls and retention limits. Alert on symptoms that require action, include a runbook link and test notifications before launch.
Common mistakes
- leaving password SSH or direct root login enabled
- opening every port to the internet
- running the application as root
- keeping secrets in source control
- assuming snapshots replace tested backups
- updating production without rollback
- filling disk with unlimited logs
- launching without certificate and service alerts
Practical checklist
- assign an owner and document inventory
- verify SSH keys and emergency access
- apply updates and remove unused services
- configure firewall and private databases
- use least-privilege service accounts
- store secrets outside source control
- configure log rotation
- back up to separate encrypted storage
- perform a restore test
- monitor health and certificate expiry
- document deploy and rollback
When hiring a technical person makes sense
Bring in senior infrastructure help when downtime affects revenue, personal data is involved, several services share the host or nobody owns recovery. A specialist can review exposure, automate the baseline and test backups without disrupting production. Compare service supervision options in PM2 vs Supervisor vs systemd.
Final takeaway
Production readiness is a recovery discipline. Keep the server minimal, observable and reproducible. See my infrastructure services or contact me for a technical review.