Gentoo on a VPS: Realistic USE Flags and Compilation Strategy

Gentoo on a VPS polarizes people, and the honest version of the argument is this: the distribution's entire value is control over what gets built, and build cost on a small VPS is real CPU time you are paying for. The purely enthusiastic take ignores economics; the purely dismissive take ignores that Portage now consumes binary packages, that profiles do most of the configuration work, and that a two- or four-core VPS can absolutely sustain Gentoo if the flags and the schedule are chosen deliberately. This post is the deliberate version: profile first, a USE budget, a compilation strategy that fits the cores you have, and the binary escape hatch.

Start From a Profile, Not From Zero

Profiles encode the distribution's opinion about your machine: which USE defaults apply, which components are mandatory, and which development defaults are sane. Choosing a server-suitable profile at install time saves an hour of flag surgery later, because the desktop-oriented profiles drag in a shelf of GUI dependencies you will spend the next maintenance window explaining to the package manager.

eselect profile list
eselect profile set <number>
emerge --info | grep -E '^USE'

A USE Budget for Two Cores

USE flags turn features on and off at build time, and each flag you drop is a dependency you never compile, configure, or patch. On a small machine the correct instinct is subtraction, not accumulation: start from the profile defaults and remove what the workload does not need, rather than collecting every feature that could possibly be useful.

# /etc/portage/make.conf — a VPS-sized budget
MAKEOPTS="-j2"
EMERGE_DEFAULT_OPTS="--jobs=1"
USE="-systemd -wayland -pulseaudio"
FEATURES="buildpkg getbinpkg"
GENTOO_MIRRORS="https://mirror.gentoo.org"

MAKEOPTS should match the core count exactly: -j2 on two cores, -j4 on four, and never more jobs than cores, because the memory budget is the real ceiling on a shared host. Overcommitting jobs past RAM is how a Gentle sysadmin pages through a 3 a.m. swap storm.

Compilation Strategy on Two Cores

The daily loop is sync, then update the world. Individual merges are minutes rather than hours, and a world update is a scheduled maintenance item, not a background surprise. The --changed-use flag rebuilds packages whose flags changed since their last merge, and @preserved-rebuild clears the queue of libraries that moved underneath running binaries.

emaint sync -a
emerge --ask --update --deep --changed-use @world
emerge @preserved-rebuild
emerge --ask --depclean

Run the world update inside tmux and treat a failed merge like any other planned change: the transaction rolls back cleanly, and pending configuration updates wait for the next slot. The output is unusually good, so read the merge plan, the USE changes, and the warnings before confirming anything.

When to Grab the Binary

Gentoo's official binary package host now covers the common stack, and the FEATURES="getbinpkg" line above makes emerge prefer a matching prebuilt. Building every package from source on a small VPS is a stance, not a requirement: source-build the packages you actually tune, and let binaries carry the ones you do not care about.

emerge --usepkg nginx
emerge --ask --usepkg @world
emerge --ask --buildpkg --usepkg @world

Pair that with a local PKGDIR and every build you do becomes a cached binary for the next machine, which is how a two-instance Gentoo fleet stops paying the compile tax twice.

Takeaway

Gentoo on two cores works when the profile decides the defaults, USE flags are subtracted instead of added, compile windows are scheduled, and binary packages carry the workload you do not care to tune. That is the difference between running Gentoo and being run by it.

Boot a Gentoo VPS on Netbay in under 60 seconds, pick a profile, and spend one afternoon watching emerge, which is the honest way to price the control it offers — netbayhosts.in.