Linux

The application needs somewhere to run. A Linux server gives the team control over processes, packages, storage and network behaviour, while making that team responsible for the operating system between the cloud console and the application.

Linux is a family of kernels, distributions and support policies rather than one server product. Ubuntu, Debian and managed provider images can all run the same web stack with different release cadences and package expectations. The useful choice is the supported build the team can reproduce and operate.

We approve self-managed Linux when that control solves a real need and the ownership survives the person who created the first instance.

The distribution choice is a support commitment

A production distribution supplies a kernel, packages, security updates, installer and lifecycle. Selecting it determines how long a release receives fixes, which library versions arrive through supported repositories and how upgrades are performed.

Ubuntu publishes release and support information for interim and long-term-support releases. Debian maintains its own release lifecycle and security support. Neither label keeps a particular server current without an update process.

We prefer a maintained release already understood by the team and supported by the application’s runtime. A newer package is not automatically safer than a distribution-patched stable package; security fixes may be backported without changing the visible upstream version.

The production inventory records distribution, release, architecture, image source and end-of-support date. That gives replacement and upgrade work a deadline.

A small server image still needs a declared purpose

Reducing installed packages can reduce attack and maintenance surface. It also removes diagnostic tools an operator may expect during an incident. “Minimal” should mean every installed service has a purpose, not that the server is difficult to inspect.

We list listening ports, enabled units, scheduled jobs, local users and package sources. A web host should not run an old mail daemon or database because an image once included it. Conversely, adding ad hoc tools directly in production creates a server the build process cannot reproduce.

The boundary between host and application matters. Nginx, PHP workers, Node processes, databases and agents may all share one small server, or some may be managed elsewhere. The diagram should match what systemctl, the process list and the network show.

Administrative access needs individual identity

SSH is often the route to a self-managed Linux host. Each operator should have an individual account or federated access, protected keys and only the privilege required. Shared root credentials make access difficult to revoke or attribute.

The OpenSSH project documents server controls in sshd_config, while distribution defaults can differ. We restrict exposed authentication methods, review privileged commands and retain an emergency access route that does not depend on the failed service.

Cloud firewalls and host firewalls should agree on intended ports. A database bound to all interfaces remains a poor design even if one provider rule currently hides it. Defence at more than one boundary protects against drift.

Access logs need useful retention and alerting without recording secrets. A successful login from an unexpected region or a burst of failed attempts should be visible before a customer reports a changed website.

Patching includes kernels, services and reboots

Security updates can affect the kernel, C library, SSH, web server and application runtime. Installing a package does not always put the patched code into the running process. Services may need restart and kernel fixes normally need reboot or a managed live-patching approach.

We maintain a regular update window, a route for urgent advisories and a way to see which hosts have drifted. Staging checks the application against pending runtime and package changes. Production changes retain health tests and rollback or replacement capacity.

Rebooting is an availability design question. One server means an interruption unless traffic can move elsewhere. Several servers need coordination so they do not all disappear together. The answer should be planned before a high-severity kernel issue sets the timetable.

Unsupported third-party repositories deserve particular care. They can delay distribution upgrades or replace core packages. Each has an owner and removal route.

Linux configuration should be replaceable, not artisanal

A server configured through an administrator’s shell history cannot be recreated reliably. We keep application deployment, packages, services, firewall intent and configuration in versioned automation where proportionate.

That does not require a large orchestration platform for one host. A documented bootstrap script, configuration tool or provider image pipeline can be enough. The test is whether a second operator can build a replacement without copying unknown state from production.

Secrets remain outside source and machine images. The server receives them through a controlled store or deployment route, with permissions and rotation. Configuration templates should fail when required values are missing rather than starting with unsafe defaults.

Drift checks compare running services and versions with the declared build. Manual emergency changes are recorded and either encoded or reversed after the incident.

Recovery starts above the virtual machine

A provider snapshot can recover a disk, but it may capture database inconsistency, old credentials or the same configuration fault that caused the incident. Application data, uploaded files, secrets and server configuration have different recovery needs.

We define which state belongs on the host. Disposable application servers keep durable data in managed databases or object storage and are easier to replace. A single-server installation needs application-aware backups, off-host copies and a restore test.

Recovery time and acceptable data loss set the design. If the business cannot wait for a fresh server and restore, it needs redundant capacity. If a few hours are acceptable, a tested rebuild may be safer and cheaper than an untested cluster.

Console access, DNS changes and backup credentials must remain available during a server failure. A runbook stored only on that server is not part of recovery.

Server monitoring must include the operating system

Application uptime does not reveal a full disk, memory pressure, clock drift, failed timer or a process repeatedly killed and restarted. Server monitoring covers capacity, service state, logs and the customer endpoint together.

Alerts need an action. High CPU during an expected report may be normal; a filesystem at 95 per cent has a clear deadline. We choose thresholds from workload and growth rather than copying a generic dashboard.

Inventory is also monitoring. The team should be able to list active hosts, owners, release versions and public addresses. An forgotten server can continue accumulating cost and vulnerability after its application has moved.

Questions to answer before owning Linux servers

• “Why does the application need host-level control?” Compare it with a managed runtime.
• “Which distribution release is supported until when?” Put the lifecycle in the inventory.
• “Who can administer the host and how is access revoked?” Avoid shared identity.
• “How are urgent patches and reboots handled?” Include service restarts and availability.
• “Can a replacement be built from versioned configuration?” Test reproducibility.
• “Which data lives on the server and how is it restored?” Keep recovery application-aware.
• “Which operating conditions trigger an actionable alert?” Monitor more than HTTP.

When self-managed Linux is justified

Choose Linux servers when the application needs specific runtimes, processes, network control or cost characteristics and the team can operate the host consistently. A small, conventional web stack can remain understandable for years with disciplined patching and automation.

The decision is strongest when servers are replaceable, durable data lives elsewhere and access belongs to the organisation. Control then supports the product rather than trapping it on one machine.

When a managed service is the better operating decision

Use a managed application platform when the workload fits its runtime and avoiding OS patching, process supervision and base-image maintenance is worth the provider constraint. The business still owns application releases and data, but the host boundary moves.

Managed databases and storage are often sensible even when application servers remain on Linux. Operating every layer personally is not evidence of better control.

And avoid a fleet of pets when there is no automation or on-call capability. One carefully maintained server can be safer than several inconsistent instances that nobody can rebuild.