Ports Collection and pkg: Installing Software the BSD Way
We still remember the first time we typed make install clean on a FreeBSD box. Watching the build scroll past — fetching distfiles, applying patches, compiling against our chosen options — felt genuinely different from typing apt install and waiting for a binary to drop into place. That moment is where most sysadmins either fall in love with FreeBSD or run back to Linux. This guide is for the ones who stayed. We are going to walk through the two halves of FreeBSD’s software system — the Ports Collection and pkg — and show how UK sysadmins can use both without tripping over themselves.
Why FreeBSD Does Software Differently
On a typical Linux distribution, you get a package manager and that is largely the end of the story. FreeBSD gives you two parallel systems that share the same metadata: the Ports Collection for building from source, and pkg for installing prebuilt binaries. They are not competitors. They are two views of the same catalogue, and understanding that relationship is the key to running a clean FreeBSD server.
For UK sysadmins running production infrastructure — whether that is a ZFS-backed storage box in a Manchester datacentre or a fleet of jails on a Bytemark host — the appeal is reproducibility. You can pin exact build options, audit every dependency, and rebuild the same package six months later with the same flags. That level of control is hard to match elsewhere.
The philosophy behind ports and packages
The Ports Collection is a tree of Makefiles, patches and distfile checksums. Each port describes how to fetch, patch, configure and compile a piece of software. When you build a port, the result is registered in the same package database that pkg uses. That means a port you compiled by hand shows up in pkg info just like a binary package would.
The pkg tool, by contrast, pulls prebuilt packages from a repository. Those packages were built by the FreeBSD project’s package builders from the very same ports tree. So the two systems are consistent by design — the difference is simply whether the compilation happens on your machine or on someone else’s.
How this differs from apt and yum
With apt or yum, you generally get one path: install the binary the distribution shipped. If you want different compile-time options, you either find a third-party repository or build it yourself and lose the ability to manage it with the system package manager.
FreeBSD avoids that split. A port built locally and a pkg installed from a mirror both live in /var/db/pkg, both respond to pkg upgrade, and both can be audited with pkg audit. That coherence is what makes mixing the two approaches practical rather than reckless.
The Ports Collection: Building from Source
The Ports Collection lives in /usr/ports and can be updated with portsnap or git. Modern FreeBSD releases have largely moved toward git, and we recommend that path if you are comfortable with it — the tree is smaller to fetch incrementally and easier to pin to a specific commit.
Fetching and updating the ports tree
On a fresh install, you can bootstrap with portsnap for a one-off fetch, but for regular updates we use git against the official FreeBSD repository. A shallow clone keeps the size manageable on smaller VPS instances. Once the tree is in place, updating is a matter of pulling the latest commit and letting the Makefiles reflect the new versions.
UK users should also configure a nearby mirror for distfile downloads. The MASTER_SITE_BACKUP and MASTER_SITE_OVERRIDE variables in /etc/make.conf let you point at a fast UK FreeBSD mirror so that large tarballs do not crawl across the Atlantic.
Using make config and OPTIONS
Every port has a set of configurable options — database backends, TLS libraries, ZFS-aware flags, optional documentation. Running make config in a port directory presents a dialog, and your choices are saved to /var/db/ports/ so subsequent rebuilds remember them.
For a ZFS root setup, this is where you enable features that matter: ARC-friendly memory limits, compression support in tools like rsync, or OpenSSL variants that match your base system. Getting these right at build time avoids painful rebuilds later.
When source builds make sense
Source builds are not a religion. We use them when:
- A port has a compile-time option we need that the default package does not enable.
- We want a newer version than the quarterly repository provides.
- We are patching a specific bug that has not yet landed upstream.
- We need to link against a custom library in /usr/local.
For everything else — nginx, PostgreSQL, Python, the usual suspects — pkg is faster and less error-prone.
pkg: Binary Packages for Busy Sysadmins
pkg is the modern replacement for the old pkg_install tools and it is what most of us reach for first. It is fast, it handles dependency resolution cleanly, and it understands the difference between quarterly and latest repositories.
Installing and removing packages
The basic commands are what you would expect. pkg install nginx pulls the package and its dependencies. pkg delete nginx removes it. pkg search queries the remote repository, and pkg info lists what is installed locally. If you have not used pkg before, run pkg bootstrap once and it will set itself up.
Switching between quarterly and latest
FreeBSD ships two main repositories. quarterly receives only security and critical fixes, which makes it the right choice for production servers. latest tracks the head of the ports tree and gets new versions as they land.
You can switch by editing /etc/pkg/FreeBSD.conf or by dropping an override into /usr/local/etc/pkg/repos/. UK users should also select nearby FreeBSD mirrors in that same configuration — the difference in latency between a European mirror and a US one is noticeable when you are upgrading a hundred packages.
Auditing and updating with pkg
Two commands belong in every sysadmin’s routine. pkg audit -F checks installed packages against the VuXML vulnerability database. pkg upgrade brings everything up to date, respecting the repository you have chosen. On a ZFS system, take a snapshot first — more on that below.
Mixing Ports and pkg Without Breaking Things
The pragmatic approach for most of us is: use pkg for the bulk of software, build a handful of ports from source where it matters. The trick is doing that without creating a mess of conflicting dependencies.
Using portmaster and synth
Two tools make mixed installations manageable. portmaster is a shell-based manager that tracks which ports you have built and rebuilds them cleanly when dependencies change. synth is a newer alternative that builds ports in a controlled environment and produces packages you can install locally — which is handy when you want to build once and deploy to several machines.
Both tools integrate with the pkg database, so anything they build is visible to pkg and vice versa.
Avoiding dependency clashes
The classic mistake is building a port that pulls in a newer library than the one pkg expects, then running pkg upgrade and watching it try to downgrade or remove things. The fix is to keep a small set of ports you build yourself, document them, and use pkg lock on the packages that must not be touched by automatic upgrades.
Keeping ZFS snapshots as a safety net
ZFS datasets can isolate /usr/local so package upgrades are snapshot-safe. Before any major pkg upgrade or port rebuild, take a recursive snapshot of the dataset holding /usr/local. If the upgrade goes sideways, rollback is a single command and takes seconds. We consider this non-negotiable on production systems.
Jails, ZFS, and Software Isolation
BSD jails allow separate package sets per jail, which suits UK hosting providers like Bytemark and Mythic Beasts who run multi-tenant FreeBSD infrastructure. Each jail gets its own /usr/local, its own pkg database, and its own update schedule.
Per-jail package sets
Because a jail has its own filesystem view, you can install nginx in one jail and Apache in another without any conflict. This isolation is one of the strongest arguments for jails over containers on Linux for certain workloads — the boundary is enforced by the kernel, not by namespaces alone.
ZFS dataset layout for /usr/local
A common layout we use is to give each jail its own dataset for /usr/local, with a parent dataset for the jail root. That way you can snapshot, replicate and quota the package tree independently. It also makes cloning trivial.
Cloning jails with pkg preinstalled
Once you have a jail with the packages you want, zfs snapshot followed by zfs clone gives you a new jail in seconds, complete with its package database. For UK sysadmins running dozens of jails for clients, this is a huge time saver — new tenant, new jail, same baseline.
Practical Tips for UK Sysadmins
Mirror selection and caching are the two things that separate a smooth FreeBSD deployment from a painful one.
Choosing fast FreeBSD mirrors
FreeBSD mirror sites are listed on the project’s website, and several UK and European mirrors offer excellent throughput. Configure them in /etc/pkg/FreeBSD.conf for pkg and in /etc/make.conf for ports. Testing with fetch against a few candidates is worth the five minutes.
Caching packages on the LAN
If you run more than a couple of FreeBSD machines, set up a local pkg proxy or mirror. pkg proxy caches downloaded packages on a central host, and a full local repository can be served over HTTP with minimal effort. In a UK office or datacentre, this cuts external bandwidth dramatically.
Automating updates with cron and pkg
A weekly cron job that runs pkg update, pkg audit -F and pkg upgrade -y — with a ZFS snapshot taken beforehand — keeps systems patched without manual intervention. Send the output to your monitoring system so failures do not go unnoticed.
FAQ
Should I use ports or pkg on a production FreeBSD server?
Use pkg for almost everything. Reserve ports for cases where you need specific compile-time options, a newer version than quarterly provides, or a local patch. Mixing is fine as long as you track what you built and lock the packages that must not be touched.
How do I pick a fast FreeBSD mirror in the UK?
Check the official FreeBSD mirror list for UK and nearby European sites, then test download speed with fetch. Configure your chosen mirrors in /etc/pkg/FreeBSD.conf for pkg and in /etc/make.conf for the Ports Collection.
Is it safe to switch from quarterly to latest?
It is safe in the sense that both repositories are built from the same tree, but latest moves faster and can introduce breaking changes. On production systems we stay on quarterly and only switch individual packages when we need a specific fix.
Can I run pkg inside a jail?
Yes. Each jail has its own package database, so you can install, upgrade and audit packages independently. This is one of the main reasons UK hosting providers use jails for multi-tenant FreeBSD setups.
What is the best way to protect against a bad upgrade?
Take a ZFS snapshot of the dataset holding /usr/local before every upgrade. Rollback is immediate and complete. Combined with pkg lock on critical packages, this gives you a reliable safety net.
Mastering both ports and pkg gives UK sysadmins the flexibility to run FreeBSD servers exactly how they need — from ZFS root setups to jailed services on Bytemark or Mythic Beasts hardware. Start with pkg for speed, reach for ports when precision matters, and keep snapshots close at hand. That combination is what makes FreeBSD such a durable platform for serious server work.