DEV Community: LK Wood IV

Docker Exit Code 137: Prove OOMKilled Before Raising Memory

LK Wood IV — Mon, 05 Oct 2026 06:57:30 +0000

Adapted from Docker Exit Code 137: Prove OOMKilled Before Raising Memory, published on TechFuelHQ.

A container has stopped with exit code 137. Before restarting it or increasing its memory limit, capture its identity, state and failure window. Those records help distinguish a container memory limit from host pressure, a stop timeout, or an external kill.

The number alone cannot tell you which happened. Bash reports fatal signals as 128 + the signal number, and Linux assigns SIGKILL number 9. But Docker returns the container command's exit status, so the command can return 137 itself. Docker also documents two non-memory routes to SIGKILL: docker kill sends it by default, while docker stop escalates to it after the timeout.

Capture one container and one time window

Replace these example values. Keep an explicit timezone: Docker events otherwise interprets timestamps in the client's local timezone.

CONTAINER='replace-with-name-or-id'
SINCE='2026-10-03T18:20:00-05:00'
UNTIL='2026-10-03T18:30:00-05:00'

First, read the stopped container's state and configured limits with Docker inspect. Save the full container ID with the output.

docker inspect --type=container \
  --format 'id={{.Id}} name={{.Name}} image={{.Config.Image}} exit={{.State.ExitCode}} oom_killed={{.State.OOMKilled}} started={{.State.StartedAt}} finished={{.State.FinishedAt}} error={{json .State.Error}} memory={{.HostConfig.Memory}} reservation={{.HostConfig.MemoryReservation}} memory_swap={{.HostConfig.MemorySwap}} oom_kill_disable={{json .HostConfig.OomKillDisable}} restart_count={{.RestartCount}}' \
  "$CONTAINER"

Next, collect the event sequence. Docker exposes separate oom, kill, die, stop and restart events. Its retained history covers only the last 256 events. Collect it promptly.

docker events \
  --since "$SINCE" \
  --until "$UNTIL" \
  --filter type=container \
  --filter container="$CONTAINER" \
  --format '{{json .}}'

docker logs --timestamps --since "$SINCE" --until "$UNTIL" "$CONTAINER"

Application logs can preserve the last completed operation or a shutdown request. A missing final message does not establish a kernel kill.

On a systemd host, collect kernel and daemon logs too. The UTC timestamps below cover the same example interval. These queries select the current boot; journalctl documents time and boot filtering.

JOURNAL_SINCE='2026-10-03 23:20:00 UTC'
JOURNAL_UNTIL='2026-10-03 23:30:00 UTC'

journalctl -k --boot=0 --since "$JOURNAL_SINCE" --until "$JOURNAL_UNTIL" --no-pager \
  | grep -Ei 'out of memory|oom-kill|killed process|memory cgroup'

journalctl -u docker.service --boot=0 --since "$JOURNAL_SINCE" --until "$JOURNAL_UNTIL" --no-pager

If the incident preceded this boot, run journalctl --list-boots. Choose the boot containing the incident and replace --boot=0 in both commands with --boot=THE_32_CHARACTER_BOOT_ID. On other hosts, use their actual kernel and daemon log mechanism.

Identify the memory boundary

State.OOMKilled=true means Docker recorded an OOM-killed state. It does not establish whether the container's own limit, a parent cgroup, or host pressure was responsible. Correlate it with the event timeline and kernel record.

A false flag is not an all-clear. Without matching evidence, keep the cause unresolved.

The inspect field memory is the container's hard limit in bytes. Zero means Docker configured no per-container hard limit; it says nothing about a parent boundary or the host's capacity. Docker distinguishes hard limits from soft reservations and warns about host OOM when memory is exhausted.

Where the host retains the container's cgroup, inspect that too. Locate the path through the host's runtime configuration. Do not borrow another machine's path.

For cgroup v2:

CGROUP_PATH='/replace/with/verified/container-cgroup-path'
cat "$CGROUP_PATH/memory.max"
cat "$CGROUP_PATH/memory.high"
cat "$CGROUP_PATH/memory.events"
cat "$CGROUP_PATH/memory.events.local"

The kernel's memory-controller documentation gives these files distinct meanings:

memory.max is the hard limit.
memory.high applies reclaim pressure without itself invoking the OOM killer.
An increase in the exact cgroup's local oom counter indicates allocation was about to fail at that cgroup's limit.
An oom_kill increase counts processes in the cgroup killed by an OOM killer. It does not identify the limiting boundary or prove the victim was the container's PID 1.
memory.events includes descendant events; memory.events.local stays local to that cgroup.

Record unavailable counters as unavailable. A replacement container's counters cannot fill the gap. Hosts using cgroup v1 need its different memory interfaces, covered in the original guide.

Choose a change the evidence supports

A matching Docker oom event and a nonzero limit still need corroboration. A kernel record naming the limiting cgroup, or a same-window increase in that exact cgroup's local oom counter, helps establish the boundary. Then compare workload peaks with the limit and investigate the application's memory configuration or a leak.

For host pressure, inventory the other workloads and host reserve. Raising one container's limit can move pressure onto the host.

For a stop-timeout escalation, investigate shutdown handling. Docker notes that shell-form ENTRYPOINT and CMD run below /bin/sh -c, which does not pass signals to the executable. Investigate signal handling or the grace period before changing memory.

For an external kill, trace the actor through daemon, service or scheduler records. If no branch is proven, retain the evidence and improve capture for the next occurrence.

Keep a short incident record:

Container ID and image:
Incident timestamp and timezone:
ExitCode / OOMKilled / RestartCount:
Configured container and proven parent limits:
Same-window Docker events:
Kernel victim and limiting cgroup, if identified:
cgroup version, exact path and counter changes:
Unavailable evidence:
Current classification, including unknown:
One change to test / result / timestamp:

The commands above collect evidence. They do not restart the container or change its limits. A restart may restore service while the cause remains unknown.

Disclosure: AI agents adapted this article from TechFuelHQ's sourced guide. The original documents a Docker and Linux documentation review on October 3, 2026; no Docker-host OOM experiment was performed for it, and this adaptation claims no new testing.

Self-hosting break-even: $23/month of SaaS, a $170 mini PC, about 9 months

LK Wood IV — Thu, 01 Oct 2026 01:16:42 +0000

Replacing $23/month in SaaS subscriptions (Google One 2TB + 1Password + Plex Pass) with a $170 mini PC drawing 15W idle breaks even in about 9 months. Replacing $10/month in Google storage with an $800 server never pays back.

Both answers come out of the self-hosting break-even calculator on my site. The gap between them is the argument. What you're replacing is the most important variable.

The ongoing side still has a bill

Self-hosting doesn't cost zero after the hardware. For a minimal stack it looks like this:

Cost item	Typical amount	Notes
Electricity	$1–4/mo	10–30W idle × 24/7 at $0.184/kWh
Backblaze B2 backup	$0.60–2/mo	~100–300GB after deduplication
Domain name	$1–1.25/mo	$12–15/yr amortized
Total ongoing	$3–7/mo	Before hardware amortization

Electricity is the biggest line. Its rate matters more than most guides acknowledge. The default is $0.184/kWh, the EIA May 2026 US residential average, where a 15W mini PC running 24/7 costs about $24/year, while at $0.13/kWh (roughly the cheapest US states, Idaho and Utah, in EIA's May 2026 residential table) the same box costs about $17/year and at California's $0.333/kWh it costs about $44/year. Use the rate on your own bill.

Two questions, kept apart on purpose

The calculator answers two different questions from the same inputs. The monthly self-host figure and the year-by-year table amortize the hardware over the lifetime you pick, so a $300 mini PC used for 5 years costs $5/month in hardware amortization and the same box used for 7 years costs $3.57/month. Break-even treats the hardware as upfront instead. It's the number of months of operating savings (SaaS cost minus electricity, maintenance and backup, with hardware amortization excluded) that it takes to recoup the purchase price.

Here are the calculator's own outputs for its defaults: Google One 2TB at $9.99/mo, Plex Pass at $6.99/mo and 1Password Families at $5.99/mo, a 5-year lifetime, 15 W idle, $0.184/kWh, $15/yr maintenance and Backblaze B2 at $1.20/mo. Only the hardware changes.

Hardware	SaaS / month	Self-host / month	Monthly savings	Break-even	5 years
$300 mini PC (default)	$22.97	$9.46	+$13.51	1.4 yr	+$810
$170 N150 mini PC	$22.97	$7.30	+$15.67	9 mo	+$940

On the $170 box the ongoing costs come to about $4.50/month (electricity $2.01, maintenance $1.25, off-site backup $1.20), or about $7.30/month once the $170 is spread over five years.

When the answer is "Never"

Now the $800 server against $10/month of Google storage. It never pays back. The operating savings alone would need about 12 years, more than two 5-year hardware lifetimes, so the calculator returns "Never" rather than a payback date.

That's deliberate. When break-even lands past the hardware lifetime you selected, the tool reports "Never", because a payback you can only reach after buying a replacement machine is not a payback. It's the same condition as the monthly-savings figure going negative.

Flip the inputs and it gets quick. Replacing $50/month in cloud subscriptions with a $200 mini PC breaks even in under 5 months.

What's worth replacing

The clear wins, where self-hosting is dramatically cheaper and reliable:

Vaultwarden for 1Password Families or Bitwarden Premium
Jellyfin for Plex Pass, with no transcoding session limits
Uptime Kuma for UptimeRobot Solo
Immich for Google One 2TB storage, if you have local storage

Nextcloud (for Dropbox or Google Drive) and n8n (for Zapier) are viable but take more effort. Nextcloud needs maintenance, and n8n has a steeper setup curve.

I'd keep paying for three things. Email, because of deliverability problems from residential IPs and high maintenance. CDN and DDoS protection, which aren't worth running yourself. Calendar sync, which is too fragile for too little savings.

Where the defaults are assumptions

The subscription presets use the vendors' published list prices at capture time. Plans change.

So confirm the current price before deciding, and treat the rest of the defaults the same way. The $0.184/kWh default is an average; your bill's effective rate is the number to use. The 15 W idle draw, $15/year maintenance and $1.20/month backup are my working assumptions for a small mini-PC stack, stated so you can replace them with your own measured numbers. The six hardware presets are street-price estimates for a class of machine. They are not quotes for a named SKU, and they aren't sourced the way the subscription prices are. Type in what you actually paid.

First published on my site, techfuelhq.com. AI agents adapted this post from that page, and every number here is copied from it.

Raw data is useful only when the caveats travel with it

LK Wood IV — Sun, 20 Sep 2026 08:03:54 +0000

When comparing public benchmark datasets, the method and limitations should travel with the download. That is the point of the TechFuelHQ dataset hub: the evidence trail is part of the data.

Use it this way:

Open the dataset page before the file. Check the collection date, test setup, attribution, correction history, and dataset-specific license.
Download the CSV or JSON. CSVs work in a spreadsheet or with pandas; JSON works well in scripts and small tools. Keep blanks as blanks instead of silently converting “not measured” into zero.
Follow the reproduction material. Depending on the release, that may be an evidence manifest, a corpus/scorer README, or a Python runner with per-repetition output. Read code before running it and preserve the documented hardware, model, and settings when comparing results.
Cite the dataset version and capture date in anything you publish.

The hub currently includes first-party GPU and local-LLM measurements, Home Assistant voice results, component-reference JSON, and price-observation CSVs. A price row describes its capture date; it is not a live-price claim. The PC-builder reference data stores compatibility attributes and source pages without storing prices.

Browse or download the files.

Disclosure: This is my site. This post was prepared and checked by AI agents; the file types and resources described here were checked against the published hub.

How to Test a UPS: Charge Is Not Health

LK Wood IV — Wed, 16 Sep 2026 19:31:55 +0000

The number on the front of a UPS is a charge reading. It is not a health reading.

A unit showing full can drop the load the moment it transfers. The display will have been telling you everything was fine right up until the instant it stopped being fine, and it was not lying — it was answering a different question than the one you thought you were asking.

That gap between charged and working is the whole subject here. Sizing the unit is settled territory: VA against watts, runtime against your shutdown window. This is about what comes after you have bought the right size — proving it does the job, on a schedule, before the power goes out and proves it for you.

The built-in self-test is not a runtime test

Most units test themselves. The test covers less than the name suggests.

Schneider's documentation for the Smart-UPS line says the unit self-tests when you switch it on and every two weeks after that, and that during the test it runs on battery for approximately ten seconds (Schneider Electric FA405317). The Back-UPS line runs the same ten seconds on a different clock — Schneider describes the automatic test as happening every seven days after the unit is powered on — and its replace-battery alarm is framed against a standard two-minute runtime limit (Schneider Electric FAQ000267818).

Ten seconds is a genuinely useful test of one thing: the transfer relay closes and the inverter comes up. Keep it enabled. But read what it is measuring. A battery that has lost most of its useful capacity will hold ten seconds without complaint, and it will hold two minutes for a while after that. By the time the automatic test starts failing, you have already been running on a battery that would not have finished a shutdown.

Charge is a percentage. Capacity is minutes. The panel shows you the first one and you need the second one.

An untested UPS is a surge protector with a battery in it

So test on a schedule, and make it a real test.

Connect the load the unit actually protects. Pull the input cord. Watch what the load does at the moment of transfer, and time how long the battery holds before the shutdown you configured actually fires. That one pull exercises the transfer, the inverter, the battery under its real load, and your shutdown chain, in the order they will happen for real.

Nothing else does. A ten-second self-test skips the load. A runtime figure from a spec sheet skips your gear. The UPS runtime calculator will model the curve for you, and the model is worth having as a starting expectation — but a modelled forty minutes and a measured forty minutes are not the same claim, and only one of them is about the battery currently sitting in your rack.

If you would rather not pull a cord on live equipment, NUT will start a deep battery test on hardware that exposes one:

upscmd -u <user> <upsname> test.battery.start.deep

test.battery.start.quick, test.battery.start.deep and test.battery.stop are all standard NUT instant commands (NUT instant command reference), and upscmd -l <upsname> lists what your specific unit supports (upscmd man page).

There is a second reason to test that has nothing to do with the battery. A UPS can fail in a way that takes the load down with it. That is a real failure mode, not a freak event. The box you bought to prevent an unclean shutdown sits in series with everything it protects, and the only way to find out how yours behaves when it goes wrong is to make it transfer while you are standing there rather than at 3am while you are not.

Pure sine, or don't put a server PSU behind it

This one has a mechanism, and the mechanism is published by the people selling the cheaper option.

CyberPower's explanation of its own PFC Sinewave line is that a simulated sine wave produces a zero-output state during the phase change — a gap in the waveform — and that this gap can interrupt equipment running an active-PFC power supply when the unit switches from mains to battery (CyberPower, PFC Sinewave Series).

Read where that failure lands. Not during a brownout, not on a slow degrade — at transfer. The single event the UPS exists to handle is the event a simulated-sine unit is worst at, and active PFC is standard in modern PC and server supplies; CyberPower's own page dates that transition to the last fifteen years.

Simulated sine into an active-PFC supply is asking for trouble on transfer. Pure sine for anything with a server PSU behind it.

USB and NUT, not a network management card

Network management cards cost absurd money next to the UPS they plug into. A UPS network management card is a separate accessory bought on top of the unit, and for a single-site homelab it buys network-side monitoring you can get from a cable.

USB plus NUT does the job and is what I'd run. Three pieces:

usbhid-ups should detect anything implementing the HID Power Device Class, with the amount of data varying by manufacturer and model. NUT lists all MGE, Dell and AMETEK Powervar USB models, the newer Eaton USB models, and specific models from APC, CyberPower, TrippLite, Belkin, Powercom and PowerWalker (usbhid-ups man page). Check your exact model against the compatibility list before you count on it.
upsmon watches for the critical condition — on battery, low charge — sets the forced-shutdown flag, and lets every machine it is monitoring run its own shutdown command with a delay you set (NUT configuration notes).
upscmd gives you the battery tests above and the alarm control below.

That is the entire feature set most homelabs wanted from the card.

If it can't trigger a clean shutdown of what's plugged into it, most of the value is gone. A UPS that only buys you a few minutes of uptime during which nobody is home to act is a very expensive way to delay the same unclean power-off. The shutdown chain is the product. Configure it the day the unit arrives, then test that it fires — which is the same plug-pull from two sections up, and the reason that test is worth doing properly.

The alarm will go off at 3am

It will. The alarm is standard equipment, and the first time it fires is the worst possible moment to be learning where the mute button is.

Decide now what you want it to do, and set it now. NUT exposes beeper.disable, beeper.mute, beeper.enable and beeper.toggle as instant commands (same reference), so this is one upscmd call, done while you are awake and thinking clearly about whether you actually want an audible alarm in that room.

Batteries are a consumable

Plan for the replacement rather than being surprised by it. Sealed lead-acid cells are on a several-year cycle, and third-party replacements are standard practice — not a corner cut.

Schneider puts most APC batteries at three to five years and notes that every 8°C (15°F) of extra operating temperature halves that life (Schneider Electric FA158934). That second figure is the one people miss. A UPS in a warm closet is not on the same schedule as the same UPS in a basement, and if you have put yours in the warm closet, the replacement year on your calendar is optimistic.

Which puts you back at the test. The only way to know where your battery is on that curve is to have measured it recently under load.

What I'd do: pure sine, USB, NUT, and a plug-pull on a schedule

Buy a pure sine wave unit sized to your load, connect it over USB, run NUT, and pull the plug on a schedule. No management card. That configuration covers the transfer, the shutdown, the alarm and the tests, and there is nothing left in the card that a homelab with one rack needs.

The plug-pull is the part people skip and the only part that produces information. Put it on a recurring reminder alongside whatever else you check, keep the number you measured, and compare it to the last one. When the measured runtime has fallen far enough that your shutdown no longer finishes inside it, buy cells — before the automatic self-test gets around to agreeing with you.

This is wrong for a few situations. Simulated sine into active PFC — do not, at any price. A consumer unit under a full rack, where the load is past what the unit is rated to hold and the runtime is theatre. And anyone who will not set up automatic shutdown, because at that point the money bought a surge protector with a battery in it, which is where this started.

Testing does not make a UPS more reliable. It tells you whether the one you own is still doing the job, which is a different and more useful thing than a green light. And none of it replaces keeping backups somewhere else — a clean shutdown protects the pool, not the data.

Originally published on techfuelhq.com.

How to Install Proxmox VE (2026): Install + Update Reference

LK Wood IV — Sat, 04 Jul 2026 16:35:39 +0000

Installing Proxmox VE is genuinely easy. The graphical installer is a few screens, and it writes itself to disk in a couple of minutes. What trips people up is not the install itself: it is the first fifteen minutes afterward, where a default install points at a repository you cannot use without paying, and the longer-term question of how you keep the thing updated once it is running.

This is the generic reference for both. It is hardware-agnostic on purpose: the steps below apply to a mini PC, a used office desktop, an old gaming rig, or a rack server. If you want a hands-on, click-by-click walkthrough on a specific small box, the Proxmox mini PC setup guide is the hardware-specific companion to this one. If you are still choosing hardware, start with the Proxmox hardware requirements. And if you already run VE 8 and want to jump to VE 9, that is a different, planned operation covered in the 8-to-9 upgrade gotchas.

Everything below is cited to the official Proxmox documentation. The current release as of this writing is Proxmox VE 9.2-1 (released May 21, 2026), built on Debian 13 "Trixie." If a command or file path is here, it is real and current for VE 9.

Part 1: The clean install (any hardware)

Step 1: Download and verify the ISO

Grab the latest Proxmox VE ISO from the official downloads page. As of June 2026 that is the VE 9.2-1 installer, about 1.7 GB.

Do not skip the checksum. The download page publishes a SHA256 value next to the ISO. After downloading, compute the hash and compare it to that published value:

# Linux / macOS
sha256sum proxmox-ve_9.2-1.iso

# Windows (PowerShell)
Get-FileHash proxmox-ve_9.2-1.iso -Algorithm SHA256

If the two strings do not match, the download is corrupt or tampered with. Delete it and re-download. This takes ten seconds and it is the one verification step that matters before you write installation media.

Step 2: Write the USB installer

A USB stick is the standard install medium. The tool depends on your OS, and the official guidance is specific about which ones work:

Linux: use dd. Identify the USB device first with lsblk, then write with dd bs=1M conv=fdatasync if=./proxmox-ve_9.2-1.iso of=/dev/XYZ (replace /dev/XYZ with your actual USB device; getting this wrong overwrites the wrong disk).
Windows: Etcher works with no configuration. Rufus also works, but you must select DD mode when it prompts, not ISO mode.
macOS: convert the ISO to a raw image, then write it (see the official media-prep page for the exact hdiutil and dd sequence).

One specific warning from the docs: do not use UNetbootin. It is incompatible with the Proxmox installer.

Step 3: Boot the installer and pick your filesystem

Plug the USB into the target machine, power on, and bring up the boot menu (commonly F11, F12, or Del). Select the USB device, then choose Install Proxmox VE.

Two decisions matter. Target disk and filesystem: select the SSD or NVMe you want Proxmox on, and be careful not to pick the USB installer drive by accident.

Filesystem	When to choose it
ext4 (default)	Single-disk machine. Simple, fast, reliable, uses an LVM-thin pool Proxmox manages natively. The right first-install answer.
ZFS	Two or more drives and you want a mirror or RAID-Z, plus snapshots, checksums, and self-healing. Wants meaningful RAM for its cache.
XFS	Offered with LVM, but far less common in Proxmox setups than ext4.
Btrfs	A technology preview. Not recommended for a production-style install yet.

The official installer note is blunt that ZFS on top of any hardware RAID is unsupported and can cause data loss, so if you run ZFS, give it the raw disks. For a first build on one drive, choose ext4 and move on.

Network and password: set a hostname, then set a static IP outside your DHCP range so the web UI always lives at the same address. Set a strong root password. The installer builds a Linux bridge called vmbr0 on your first NIC so VMs and containers can reach the network. Click install; it writes to disk in a few minutes and reboots.

Step 4: Reach the web interface

Point a browser on another machine at the IP given during install, on port 8006:

https://your-ip:8006

Note the https and the :8006. Plain http or a missing port is the single most common "it didn't work" mistake, and the install is almost certainly fine. You will get a certificate warning because Proxmox uses a self-signed cert; accept it and log in as root.

Part 2: The first fifteen minutes (the repository fix)

This is the part generic install guides skip, and it is the one step every Proxmox install needs. A fresh install points apt at the enterprise repository, which requires a paid subscription. Without a key, every apt update ends in 401 Unauthorized and your package lists never refresh.

Proxmox VE 9 also changed the repository file format to the deb822 .sources format, so the files look nothing like the one-line sources.list entries from VE 8.

Disable the enterprise repository

Open the node shell (web UI, your node, Shell) and edit /etc/apt/sources.list.d/pve-enterprise.sources, adding a single line so it reads Enabled: no. That suppresses the enterprise repo without deleting it.

Enable the no-subscription repository

Create the no-subscription sources file with the exact deb822 contents the docs publish for VE 9:

# /etc/apt/sources.list.d/proxmox.sources
Types: deb
URIs: http://download.proxmox.com/debian/pve
Suites: trixie
Components: pve-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg

You can do all of this from the web UI instead: node, Updates, Repositories, Add, pick No-Subscription, then highlight the enterprise row and click Disable. The GUI writes the same files for you.

The no-subscription repo ships the same packages as enterprise without a key. Proxmox is explicit that these are "not always as heavily tested and validated," so it is fine for a home lab but is not their recommendation for production.

Run the first update

apt update
apt full-upgrade

Use full-upgrade, not plain upgrade, more on why in Part 3. Reboot if a new kernel was installed. The subscription-nag popup at login is cosmetic; click OK and move on.

Part 3: How to update Proxmox over time

Once Proxmox is running, "update" means two very different things, and conflating them is where homelabs get into trouble.

Routine updates (within a major version)

Normal maintenance, keeping VE 9 current as point releases ship (9.1 to 9.2). From the shell, apt update then apt full-upgrade; or in the web UI, select the node, open Updates, Refresh, then Upgrade.

Why full-upgrade and not apt upgrade? Plain upgrade refuses to install anything that requires a new dependency, and on Proxmox that means the kernel and the pve-manager stack get held back, exactly the packages you want updated. full-upgrade installs them. A reboot is only needed when a new kernel arrives.

Major upgrades (across major versions)

Moving from VE 8 to VE 9 is a different animal. It crosses to a new major version, which moves the underlying Debian base and kernel, and it carries real breaking changes: LVM autoactivation defaults change, network interfaces can be renamed, and PCI passthrough can need attention. That is a planned event with its own pre-flight checklist: back up first, run the pve8to9 --full checker, pin your NIC names, and have console access that is not the web GUI. The full procedure is in the Proxmox VE 8 to 9 upgrade guide. VE 8.4 gets security and bug-fix updates until August 2026, so there is no pressure to rush.

Common install gotchas

apt update returns 401 Unauthorized. You are still on the enterprise repository. Disable it and enable pve-no-subscription (Part 2). This is the number-one new-user issue.
The web UI will not load. You used http instead of https, or forgot :8006. The correct URL is https://your-ip:8006.
VMs will not start ("KVM not available"). Hardware virtualization (Intel VT-x or AMD-V) is disabled in the BIOS/UEFI. Reboot into firmware and enable it, plus IOMMU (VT-d / AMD-Vi) if you plan passthrough.
You picked ZFS and the host feels short on RAM. ZFS reserves RAM for its cache. Size it deliberately.
You accidentally installed onto the USB stick. Always confirm the target disk in the installer is your internal SSD/NVMe.

After the install: what to build

For a screen-by-screen walkthrough on a specific small machine, follow the Proxmox mini PC setup guide.
For each service, decide between a container and a full VM. The LXC vs VM in Proxmox guide has the decision tree.
To size your box, how many VMs and containers your RAM and cores can support with ZFS overhead included, the Proxmox capacity planner does the math.

The install is the easy part. The repository fix is what makes updates work, and knowing the difference between a routine update and a major upgrade is what keeps the box healthy for years.

Sources

Originally published at techfuelhq.com.