Software and Dependency Setup

Back to Server Setup · Operating System and Stack · Dependency Checker · Service Offerings

Runtimes, databases, and application stacks installed at pinned, tested versions rather than “latest” and hoping for the best. The version numbers were chosen under operating system and stack; this step is about making those choices stick, on every machine, every time.

1. Why “Latest” Is a Bug

Installing the latest version means the version you get depends on the day you installed. Three consequences follow, and all of them cost time later:

• Environments diverge. Development installed in March, production in June, and the difference is discovered by a failure that reproduces nowhere else.
• Rebuilding is not reproducible. Rebuilding the same machine after a failure gives you a different machine, which is the worst moment to find out.
• Upgrades happen by accident. A routine rebuild pulls in a new major version with a breaking change nobody read about, and the change is discovered rather than decided.

Pinning does not mean freezing. It means the version changes when someone decides it should, having read what changed — which is the difference between an upgrade and an incident.

2. Pin at Every Layer

• System packages — from the distribution's repositories, which is the version the distribution patches. Where a newer version is genuinely required, add the upstream repository deliberately and record that you have taken on responsibility for tracking it.
• Language dependencies — a lockfile, committed, resolving the whole transitive tree to exact versions. A top-level pin with unpinned dependencies underneath is not pinned.
• Container images — a specific tag, and for anything that matters a content digest, because tags can be moved to point at different content.
• Everything you download. If the build fetches something from a URL, verify a checksum or signature. A build that trusts whatever a server returns today is a build that can be changed by someone else.

3. Where the Software Comes From

Supply chain sounds abstract until you trace what a build actually pulls in. Practical measures:

• Prefer distribution and official upstream sources over a convenient script piped from an unfamiliar site.
• Verify signatures where the project publishes them.
• Mirror or cache what you depend on. A build that fails because a public registry is down or a package was removed is an avoidable outage.
• Record what went in. A generated inventory of every component and version — a bill of materials — is how you answer “are we affected?” on the day a vulnerability is announced, in minutes rather than days. Our free dependency checker reads a lockfile and reports what is in it.

4. Configuration Is Part of the Install

A database at its shipped defaults is configured for an unknown machine, and the defaults are usually conservative to the point of being wrong for a dedicated server. The install is finished when the configuration matches the hardware and the workload — memory allocation, connection limits, worker counts — which is the subject of performance tuning.

Two rules that save a great deal of trouble: configuration lives in version control, not only on the machine; and secrets do not live in it. Credentials belong in a secret store or an environment injected at runtime, never committed alongside the configuration that references them.

5. Plan the Upgrade While Installing

Pinned versions are only safe if something moves them. Before handover we establish who watches for security advisories affecting these components, how often versions are reviewed, whether updates within a version are automatic — see security settings — and how a major upgrade would be tested. Pinning without a review cadence is how a system arrives at four years out of date with nobody having decided that.

What You Get

• Every component installed at a recorded, pinned version, reproducible from code.
• Lockfiles and image digests committed, so a rebuild produces the same system.
• A component inventory you can search when an advisory lands.
• Configuration in version control, secrets kept out of it.
• A stated review cadence and upgrade path per component.