The homelab series grows from six books to nine today. The three new ones cover the parts that turn a pile of machines into something you can trust: knowing when it breaks, running apps without the mess, and being able to rebuild the whole thing from a repository. They are written the same way as the first six: short chapters, real configs and commands, diagrams instead of walls of text, a checklist and a cheat sheet at the end. Every version number was checked against the project's own releases page or documentation in October 2026, and the books say where.

Each book is a PDF and EPUB, $19, and each one has a free sample: the cover, the full table of contents and one complete chapter.

Which one to start with

• You find out something broke when a person notices: Book 7, Watch Your Homelab.
• Your Docker host is a folder of half-remembered docker run commands: Book 8, Containers Without the Chaos.
• You could not rebuild your lab from scratch without a weekend of clicking: Book 9, Automate Your Homelab.

Book 7: Watch Your Homelab

Monitoring, Alerts and Logs for Proxmox, Docker and Home Assistant with Prometheus, Grafana, Uptime Kuma and ntfy

The monitoring stack that tells you first, and only when it matters. It answers three questions for every machine you run (is it up, is it healthy, what happened?) with free, self-hosted tools: Uptime Kuma checks from the outside, Prometheus with node_exporter and cAdvisor for metrics, the Proxmox and Home Assistant exporters, Grafana dashboards that each answer one question, alert rules routed to your phone through ntfy, and logs in Loki shipped by Grafana Alloy (Promtail reached end of life on March 2, 2026).

Inside: Uptime Kuma monitors, retries, push heartbeats for backups and cron jobs, and a status page; self-hosted ntfy with access tokens and a priority ladder; a Prometheus stack with both retention limits set; Proxmox metrics through prometheus-pve-exporter with a read-only PVEAuditor token; SMART disk health and UPS status through NUT; a disk-fill ETA panel with predict_linear; alert rules with for: durations and Alertmanager routing; a runbook template and a monthly review.

58 pages, 25 diagrams. The free sample is all of Chapter 2, "Is It Up? Uptime Kuma".

Get the book · Read the free sample

Book 8: Containers Without the Chaos

Docker Compose, Reverse Proxies, Automatic HTTPS and Single Sign-On for Self-Hosters

Self-hosted apps on Docker without the mess: one Docker host in a Proxmox VM, one folder per stack, one reverse proxy as the only front door, real trusted HTTPS for internal names without opening a single port, one good login in front of every app, updates you choose instead of surprises, and backups you have actually restored.

Inside: where Docker should live on Proxmox and what the Proxmox docs recommend; the official Docker Engine install on Debian with log rotation set before the first container; why published ports skip ufw; every part of a compose.yaml you will use, plus a complete copy-ready stack; a tidy /srv/stacks layout with one shared proxy network; Caddy in front of everything with a DNS-01 wildcard certificate and split DNS at home; Authelia single sign-on with forward auth and two-factor; Compose secrets, pinned tags and Diun update notifications (Watchtower's repository was archived in December 2025); two-layer backups; and a troubleshooting routine that starts with evidence instead of deleting things.

63 pages, 22 diagrams. The free sample is all of Chapter 3, "Anatomy of a compose.yaml".

Get the book · Read the free sample

Book 9: Automate Your Homelab

Ansible, Cloud-Init, OpenTofu and Git for a Proxmox Lab You Can Rebuild in an Afternoon

A lab you can rebuild: the definitions live in Git, the secrets live in a vault, the data lives in your backups, and a timed rebuild drill proves the three fit together.

Inside: a self-hosted Forgejo repository with a push mirror and a repo layout that scales from three VMs to thirty; the Debian 13 cloud image turned into a Proxmox template with qm, SSH keys and a vendor snippet, and full clones that personalize themselves on first boot; VMs and containers declared with OpenTofu and the bpg/proxmox provider behind a least-privilege API token; Ansible inventory, ansible.cfg, idempotency, --check and --diff; a baseline role for every Debian box (users, SSH hardening with a drop-in, unattended-upgrades, time sync); Docker hosts and compose stacks deployed from the repository with secrets in ansible-vault; what is realistic for OPNsense and Home Assistant (scheduled config backups into Git and a documented restore path); and CI on Forgejo Actions with ansible-lint and tofu validate on every push, drift checks and the rebuild drill step by step.

58 pages, 22 diagrams. The free sample is all of Chapter 3, "Golden Images with Cloud-Init".

Get the book · Read the free sample

How they fit with the first six

Book 1 sets up Proxmox, OPNsense and Home Assistant; Book 3 is the backup playbook; Book 5 locks down the network; Book 6 makes Home Assistant automations reliable. The new three assume those exist and build on them: Book 7 watches all of it, Book 8 is where your self-hosted apps live, and Book 9 is how the whole lab gets written down and rebuilt. Each book stands on its own, with cross-references where another book goes deeper.

Bundles

All nine homelab books are in the Homelab Bundle ($59), and every book in the store, the Android series included, is in the Everything Bundle ($89). The code RIGHTWAY20 takes 20% off any order through October 31.

Go deeper: Containers Without the Chaos

Your photos, your files and your passwords, running on a small box in your house. That is the whole promise of self-hosting your life: Immich instead of Google Photos, Nextcloud (or Syncthing) instead of Drive, Vaultwarden instead of a cloud password manager.

None of the individual installs is hard. What goes wrong is the layout around them. Each stage of the build has one classic trap, and each trap has a short, documented fix. Here is the path end to end.

Trap 1: one disk, one bad day

The most common beginner layout is a single SSD holding Proxmox, the containers and every photo you own. When that SSD wears out or fills up, you lose the server and the data at the same moment, and the restore needs the very disk that died.

The fix: separate the system from the data. A small SSD (256 to 512 GB) holds Proxmox and the guests' virtual disks, databases included. A second, large drive holds the photo library, the Nextcloud files and backups waiting to go elsewhere.

Then run all three apps in one Debian 13 VM as a Docker host. Immich's documentation recommends a full VM and calls Docker inside an LXC container not recommended, possible only for advanced users. Give the VM at least 8 GB of RAM (12 to 16 GB is comfortable) and set its CPU type to host or x86-64-v2-AES, because Immich's machine-learning container needs the x86-64-v2 instruction level.

Inside the VM, mount the data disk by its label, with nofail:

mkfs.ext4 -L data /dev/sdb
mkdir -p /srv/data
echo "LABEL=data /srv/data ext4 defaults,nofail 0 2" >> /etc/fstab
mount -a && df -h /srv/data

The label means a reordered disk never mounts in the wrong place, and nofail means a missing disk still lets the VM boot so you can fix it over SSH.

Trap 2: the Immich database on a network share

Immich keeps your files on disk and everything else (who is in the photo, which album it belongs to, where the file lives) in Postgres. The documentation is blunt: the database belongs on local SSD storage, never on a network share of any kind. Point DB_DATA_LOCATION at the NAS and a network hiccup during a write can leave Postgres corrupted and the timeline empty.

The second Immich trap is the version: the server only talks to mobile apps of a compatible major version, so running latest with auto-updates can silently stop your phone backups.

The fix is a handful of lines in .env:

UPLOAD_LOCATION=/srv/data/immich
DB_DATA_LOCATION=/opt/immich/postgres
IMMICH_VERSION=v3
DB_PASSWORD=ChangeMeToALongRandomString

Library on the data disk, database on the SSD, pinned to the major version. Use only letters and digits in the password; the docs warn that special characters confuse Docker's parsing. Turn on the storage template (Administration → Settings → Storage Template) before the first upload, so the library on disk is a readable year/month/day tree.

Trap 3: the hand-built Nextcloud

Web server, PHP, database, Redis, cron jobs and a dozen tuning settings, all by hand. Each piece is easy; together they are a full-time hobby, and months later the admin page is a wall of warnings.

The fix: first decide honestly what you need. A folder that stays the same on your laptop and phone is a Syncthing job. Documents, family sharing, calendars and contacts is a Nextcloud job, and then Nextcloud All-in-One (AIO) is the way: the official Docker setup that runs and updates the whole stack for you. Set NEXTCLOUD_DATADIR=/srv/data/nextcloud in the start command before the first start, because it can't be changed later without a fiddly migration. And don't rename the nextcloud-aio-mastercontainer container; AIO's self-updates depend on that exact name.

Trap 4: open signups and plain HTTP on Vaultwarden

Leave registration open and anyone who finds your URL can create an account; bots scan for exactly that. Serve it over plain HTTP and the web vault fails, because it relies on browser crypto APIs that most browsers only allow over HTTPS.

The fix is in the compose file:

SIGNUPS_ALLOWED: "false"
INVITATIONS_ALLOWED: "true"
SHOW_PASSWORD_HINT: "false"
ports:
  - "127.0.0.1:8081:80"

Generate the admin token as an Argon2 hash with docker run --rm -it vaultwarden/server /vaultwarden hash, paste it in, and double every one of its five dollar signs, or Docker Compose silently breaks it. Then chmod 600 /opt/vaultwarden/compose.yaml, turn on two-step login, and print an emergency sheet with your vault URL, email and master passphrase.

Trap 5: forwarding ports to everything

Forward port 443 on the router to the server and every service is reachable from the whole internet; within hours your logs fill with bots trying /admin and /wp-login.php.

The fix: Tailscale on the Docker VM as a subnet router, so your phone reaches home with no open router ports:

tailscale up --advertise-routes=192.168.10.0/24

Approve the route in the admin console and disable key expiry for the server. For real HTTPS names, use a reverse proxy with a wildcard certificate from the DNS challenge, with *.example.com pointing at the proxy's private address. If family members need a shared album link, forward only 443, only to the proxy, and never expose Vaultwarden or the AIO admin interface.

Trap 6: the backup that isn't one, and updates that are never or always

A file copy of a running database can restore as garbage. For Vaultwarden, use its built-in online backup in a nightly script:

docker exec vaultwarden /vaultwarden backup
tar -czf /srv/data/backups/vw-$(date +%F).tgz \
  -C /opt/vaultwarden data compose.yaml

Put the whole Docker VM on Proxmox Backup Server with a nightly snapshot-mode job, add an off-site copy, and test a restore once a quarter. On the bad day, restore passwords first: Vaultwarden comes back from the newest vw-*.tgz on any Linux machine with Docker, and it unlocks everything else.

For updates, never updating leaves known holes open, and auto-pulling every new image lands breaking releases at 3 AM. Pick a monthly maintenance hour and snapshot before touching anything:

qm snapshot 201 pre-update-$(date +%Y%m%d)
cd /opt/immich
docker compose pull && docker compose up -d

On the Proxmox host itself, use apt full-upgrade, never plain apt upgrade. Then test each app, and delete the snapshot so it doesn't slowly fill thin storage.

Checklist

• System and guest disks on an SSD; photos and files on a separate data drive mounted by label with nofail
• One Debian 13 VM as the Docker host, CPU type host or x86-64-v2-AES
• Immich: DB_DATA_LOCATION on local SSD, IMMICH_VERSION=v3, storage template on before the first upload
• Nextcloud via AIO with NEXTCLOUD_DATADIR set before the first start, or Syncthing with file versioning on
• Vaultwarden: signups off, HTTPS only, Argon2 admin token with doubled dollar signs, two-step login, emergency sheet printed
• Tailscale subnet router, key expiry off; no ports forwarded except 443 to the proxy if you must share
• Nightly PBS job, Vaultwarden online backup in cron, an off-site copy, a dated quarterly restore test
• A monthly update hour that starts with a snapshot

Go deeper: Self-Host Your Life

Your dog barks at the front door. A subtitle fades in under him: "THE MAILMAN HAS RETURNED. I WILL HANDLE THIS." That is the whole idea behind Pawdub, a new Android app from Hartmann Studios. It is for fun, and it says so on the first screen: no app can translate animals, and Pawdub never claims to. What it does do is listen and look for real, then pick a line that fits.

What actually happens

Point the camera at your dog or cat. The app listens for a bark, whine, growl, howl, meow, purr or hiss, detected on your phone. When it hears one, a movie-style subtitle appears. No sound, no subtitle. It also looks at the scene (a door, a food bowl, the couch, a toy, a bed), so the joke matches the moment: a cat at the window gets a different line than a cat at an empty bowl.

The lines themselves are jokes written for each persona. They are not a reading of what your pet means, and the app gives no advice about your pet's health, mood, training or behaviour. If you are worried about your pet, talk to a vet.

Personas

Eight of them: Drama Queen, Golden Retriever Energy, Grumpy Old Man, Royal Highness, Tiny Gremlin, Food Critic, Conspiracy Theorist and Noir Detective. Each one has its own voice and its own set of lines, so the same bark becomes a very different movie depending on who is "talking".

59 languages, offline

Subtitles come in English, Spanish, Portuguese, French, German, Japanese, Korean, Hindi, Arabic and 50 more. Each language is downloaded from Google once and then works offline. Pro adds bilingual subtitles.

Clips you already have

Open a video from your gallery and Pawdub adds subtitles to the moments where your pet makes a sound. Styles: Cinema and Meme are free; Pro adds Bubble (a speech bubble that follows your pet) and Text message.

The rest

• Pet voices: hear the line read aloud with your phone's text-to-speech.
• Pet profiles for every dog and cat in the house.
• Bark diary: a log of what your pet "said" today.
• Stickers and poster templates made from your clips.
• Export to your gallery and share anywhere.

Free and Pro

Free: unlimited live dubbing, a few exports a day with a small Pawdub tag, 3 personas, your language plus one more, the Cinema and Meme styles, and a starter sticker pack. Ads appear in the free version, never on the camera screen.

Pro: every persona, all languages, every style, all voices, longer gallery clips, write your own lines, unlimited exports without the tag, and no ads. It is sold as a subscription with a free trial for new subscribers, or as a one-time lifetime unlock; prices are shown in Google Play.

Privacy

Everything runs on your phone with on-device AI. The microphone and camera are used only while the camera screen is open, audio and video are processed on the device and never uploaded, and there is no account. Delete a clip from the library, or everything from Settings > Delete all data. The privacy policy is at chartmann1590.github.io/pawdub-site/privacy.

Pawdub has been submitted to Google Play and is in review. Until the listing is live, the Pawdub site has the screenshots and the promo video; this post gets the Play link the day it goes live.

Pawdub: Funny Pet Translator: coming soon to Google Play

You open an older Android project, bump the Android Gradle plugin to 9, and sync. The build stops with one of two messages: "Cannot add extension with name 'kotlin'" or "The 'org.jetbrains.kotlin.android' plugin is no longer required". Nothing in your code changed. The build files did not keep up with AGP.

This post covers what changed in AGP 9, the small set of edits that fix it, and two related surprises: kapt and the Material icons. Everything here comes from Chapter 2 (Thinking in Composables) and Chapter 8 (Saving Data: Room and DataStore) of Compose Without the Confusion.

The trap: applying Kotlin twice

Since Android Gradle plugin 9.0, Kotlin support is built into AGP itself. You no longer apply the separate org.jetbrains.kotlin.android plugin. Older projects apply it anyway, because that was the rule for years. With AGP 9 the plugin and AGP both try to set up Kotlin, and the sync fails with the messages above.

There is a second leftover in most older modules: an android { kotlinOptions { } } block. That block belonged to the old plugin, so it has to move too.

The fix: three edits

Google documents the migration for built-in Kotlin. In short:

1. Remove the kotlin-android plugin from your build files.
2. Remove it from your version catalog as well, so nothing re-adds it.
3. Move any android { kotlinOptions { } } block to kotlin { compilerOptions { } }.

One plugin stays. You still apply the Compose compiler plugin. It ships with Kotlin and uses the same version number, so it points at the kotlin version in your catalog.

What a working AGP 9 setup looks like

Here is the version catalog from the book's sample project, using the versions current at the time of writing (October 2026):

# gradle/libs.versions.toml (excerpt)
[versions]
agp = "9.4.0"
kotlin = "2.4.21"
ksp = "2.3.12"
composeBom = "2026.09.00"
activity = "1.13.0"
lifecycle = "2.11.0"

[libraries]
compose-bom = { module = "androidx.compose:compose-bom", version.ref = "composeBom" }
compose-ui = { module = "androidx.compose.ui:ui" }
compose-ui-tooling = { module = "androidx.compose.ui:ui-tooling" }
compose-ui-tooling-preview = { module = "androidx.compose.ui:ui-tooling-preview" }
compose-material3 = { module = "androidx.compose.material3:material3" }
compose-icons-core = { module = "androidx.compose.material:material-icons-core" }

[libraries.activity-compose]
module = "androidx.activity:activity-compose"
version.ref = "activity"

[plugins]
android-application = { id = "com.android.application", version.ref = "agp" }
kotlin-compose = { id = "org.jetbrains.kotlin.plugin.compose", version.ref = "kotlin" }

Notice what is missing from [plugins]: there is no kotlin-android entry. The only Kotlin-related plugin is kotlin-compose, and its version is the Kotlin version.

The module build file is just as short:

// app/build.gradle.kts (excerpt)
plugins {
    alias(libs.plugins.android.application)
    alias(libs.plugins.kotlin.compose)
}

android {
    namespace = "com.example.pantry"
    compileSdk = 36   // use the newest stable API level your AGP supports
    defaultConfig {
        applicationId = "com.example.pantry"
        minSdk = 24
        targetSdk = 36
        versionCode = 1
        versionName = "1.0"
    }
    buildFeatures { compose = true }
}

Two plugins. No kotlinOptions inside android { }. If your module still has compiler flags, they go in a top-level kotlin { compilerOptions { } } block instead.

The second trap: kapt

If your project uses Room, Hilt or another annotation processor through kapt, the plugin cleanup is not the end. With AGP 9's built-in Kotlin, the old kotlin-kapt plugin is not compatible. Google's migration guide recommends moving to KSP, and offers com.android.legacy-kapt only as a stopgap. Room, Hilt and most annotation processors support KSP today.

Moving Room to KSP is a few lines. The catalog gets the KSP and Room plugins (the ksp version is already in [versions] above):

# gradle/libs.versions.toml (additions)
[versions]
room = "2.8.5"

[libraries]
room-runtime = { module = "androidx.room:room-runtime", version.ref = "room" }
room-ktx = { module = "androidx.room:room-ktx", version.ref = "room" }
room-compiler = { module = "androidx.room:room-compiler", version.ref = "room" }

[plugins]
ksp = { id = "com.google.devtools.ksp", version.ref = "ksp" }
room = { id = "androidx.room", version.ref = "room" }

And the module applies them, swapping kapt(...) for ksp(...) on the compiler:

// app/build.gradle.kts
plugins {
    // ...
    alias(libs.plugins.ksp)
    alias(libs.plugins.room)
}

room {
    schemaDirectory("$projectDir/schemas")
}

dependencies {
    implementation(libs.room.runtime)
    implementation(libs.room.ktx)
    ksp(libs.room.compiler)
}

The Room Gradle plugin's schemaDirectory writes a JSON description of every database version into your project. Commit those files. Room uses them for automatic migrations and for migration tests.

Hilt works the same way. It is built on Dagger and processed with KSP. At the time of writing the Dagger and Hilt release is 2.60.1.

The third trap: icons that stop resolving

This one is not AGP, but it tends to arrive in the same upgrade. Since Material 3 1.4.0, the library no longer pulls in material-icons-core for you. Its release notes say so. After the upgrade, Icons.Default.Add suddenly does not resolve, and the error looks unrelated to anything you touched.

The fix is to add the artifact yourself. It is already in the catalog above as compose-icons-core, and the BOM still manages its version:

dependencies {
    implementation(platform(libs.compose.bom))
    implementation(libs.compose.ui)
    implementation(libs.compose.material3)
    implementation(libs.compose.icons.core)   // Icons.Default.*
    implementation(libs.compose.ui.tooling.preview)
    implementation(libs.activity.compose)
    debugImplementation(libs.compose.ui.tooling)
}

The BOM line is the one that saves you the most pain. You declare one BOM version and leave the version off every individual Compose library. The BOM picks a set of versions that were tested together.

Checklist for an AGP 9 upgrade

• Remove org.jetbrains.kotlin.android from every module and from the version catalog.
• Move android { kotlinOptions { } } to kotlin { compilerOptions { } }.
• Keep the Compose compiler plugin (org.jetbrains.kotlin.plugin.compose) at your Kotlin version.
• Replace kapt with KSP. Use com.android.legacy-kapt only as a stopgap.
• For Room, add the Room Gradle plugin, set schemaDirectory, and commit the schema files.
• If Icons.Default stops resolving, add material-icons-core and let the BOM version it.
• Leave versions off individual Compose libraries and let one BOM version pick them.

Go deeper: Compose Without the Confusion

Every messaging app you use depends on the same thing: a working connection to the internet. On a trail, at a crowded festival, or after a storm knocks out service, that dependency is exactly what fails. MeshTalk works without it. It uses Bluetooth mesh networking to connect phones directly to each other, with no internet, no cellular service, and no router or hotspot.

How the mesh works

In a mesh, each phone is both a client and a relay. MeshTalk connects to nearby devices automatically, and messages hop from device to device to reach their destination. The listing's point is that this works in areas with no signal at all, because nothing in the chain needs a tower or a server.

The practical consequence is that the more people nearby are running the app, the more paths a message has to travel.

What it does

Text chat

• Send messages to anyone in range.
• Group chats.
• Message history.
• Read receipts.

Voice

• Walkie-talkie style voice.
• Full-duplex audio, so both sides can talk at once.
• Multiple channels.
• Low battery use, according to the listing.

On-device AI

• AI message suggestions.
• Smart reply generation.
• Translation between languages.
• All AI features run locally on the phone.

The translation feature is a useful addition for an app like this. If you are at an event or travelling with people who speak another language, the translation still works when nobody has signal, because it does not depend on a server.

Privacy

MeshTalk has no accounts and no phone numbers. Messages stay on the devices, there is no cloud and there are no servers, and the listing describes it as end-to-end by design. Since there is no central server in the system, there is no central copy of your conversations to leak.

Where it makes sense

The listing names four situations:

1. Hiking, camping and outdoor events, where coverage is weak or nonexistent.
2. Disaster preparedness, for when normal networks are down.
3. Crowds with poor signal, where the cell network is overloaded even though it technically exists.
4. Privacy-conscious users, who want a messenger with no account and no server.

For the preparedness case, the thing to remember is that you set this up before you need it. Install the app on the phones of the people you would want to reach, and try it once while everything is working.

Good to know

• Price: free to download, with an optional premium upgrade mentioned in the listing; the Play listing also notes in-app purchases.
• Ads: the app contains ads.
• Range: messages reach people in range, extended by hops between other devices running the app.
• Everyone needs it: the mesh only includes phones running MeshTalk, so the people you want to talk to need it installed too.
• No sign-up: no account and no phone number are needed.

Is it for you?

• You hike, camp or go to events where your phone usually shows no bars.
• You want a way to reach family or a group if networks go down.
• You want walkie-talkie style voice between phones without extra hardware.
• You want a messenger with no account, no phone number and no server.

Get MeshTalk: Bluetooth Mesh Chat on Google Play

Most of an Android project can be changed later. A screen can be redesigned, a library swapped, a name on the store edited. Two things are different. The application ID and the signing setup are decided before your first upload, and changing either one afterwards ranges from painful to impossible.

Both take minutes to get right. Here is what to do, with the code from Ship Your First Android App.

The trap: com.example goes live

Every tutorial starts with com.example.something. It works fine on your phone, so it is easy to forget. Then the first bundle goes up to Play Console and the placeholder becomes the app's permanent identity.

Android's documentation is blunt about this. Once you publish, you should never change the applicationId in app/build.gradle.kts, because if you change it, Google Play treats the upload as a completely different app. Your installs, ratings and reviews stay with the old ID.

The fix: pick an ID you can live with forever

The naming rules from developer.android.com:

• At least two segments, separated by dots.
• Each segment starts with a letter.
• Only letters, digits and underscores: [a-zA-Z0-9_].

The convention is your domain, reversed, plus the app: com.yourname.torchlight. If you have no domain, a reversed form of a name you control works. What matters is that it is unique and yours. Replace com.example before the first upload, while it is still free to change.

One thing that confuses people: namespace and applicationId start out identical, but they are different things. The namespace is only the Kotlin package for the generated R and BuildConfig classes and can be refactored any time. The application ID is the public identity. Changing one does not change the other.

The second decision: how your app is signed

Every Android app is signed, and devices only install an update signed by the same key as the installed version. Google Play splits this into two keys:

Play App Signing is required for new apps, and new apps are automatically enrolled with Google-generated keys. Your job is only the upload key. Play Console asks for an RSA key of 2048 bits or more in a Java keystore, and Android's signing guide recommends a validity of at least 25 years:

keytool -genkeypair -v \
  -keystore upload-keystore.jks \
  -alias upload \
  -keyalg RSA -keysize 2048 \
  -validity 10000

-validity is in days. 10,000 days is a little over 27 years.

Where the key must not live

The common mistake is keeping the keystore in the project folder and committing it to Git, or keeping the only copy on one laptop. Store the .jks file outside the repository, back it up in at least two places (for example an encrypted cloud drive and a USB stick), and keep the passwords in a password manager. Google can reset a lost upload key, but a reset takes a support request and waiting, and a leaked key lets someone else upload as you until it is reset.

Wire signing into Gradle without leaking passwords

Never write passwords into build.gradle.kts. Put them in a keystore.properties file in the project root:

# keystore.properties (add this file to .gitignore!)
storeFile=/home/you/keys/upload-keystore.jks
storePassword=your-keystore-password
keyAlias=upload
keyPassword=your-key-password

And add these lines to .gitignore right away:

keystore.properties
*.jks
*.keystore

Then load it in app/build.gradle.kts. This version also reads environment variables, so the same file works on a build server later, and someone who clones the project without the keys still gets a working unsigned build instead of an error:

import java.io.FileInputStream
import java.util.Properties

val keystoreProps = Properties().apply {
    val f = rootProject.file("keystore.properties")
    if (f.exists()) FileInputStream(f).use { load(it) }
}
fun signingValue(key: String, env: String): String? =
    System.getenv(env) ?: keystoreProps.getProperty(key)

android {
    signingConfigs {
        create("release") {
            val path = signingValue("storeFile", "RELEASE_STORE_FILE")
            if (path != null) {
                storeFile = file(path)
                storePassword =
                    signingValue("storePassword", "RELEASE_STORE_PASSWORD")
                keyAlias = signingValue("keyAlias", "RELEASE_KEY_ALIAS")
                keyPassword =
                    signingValue("keyPassword", "RELEASE_KEY_PASSWORD")
            }
        }
    }
    buildTypes {
        release {
            optimization { enable = true }
            // Sign only when keys are available; otherwise build unsigned.
            if (signingValue("storeFile", "RELEASE_STORE_FILE") != null) {
                signingConfig = signingConfigs.getByName("release")
            }
        }
    }
}

The book's example comes from a real repository: the author's Flashlight app (chartmann1590/Flashlight) ships a keystore.properties.example with empty values, so anyone who clones the project knows exactly what to provide without anything being exposed.

A bonus rule: versionCode only goes up

Every upload needs a versionCode greater than the one before, and a value can never be reused. That includes builds uploaded to internal tests and builds you later abandon. The author's Dosely app is the book's example: version 1.1.1 had to go out as versionCode 4 because versionCode 3 had already been used by an earlier upload.

The greatest value Google Play allows is 2100000000. Don't jump to a huge number "to be safe" or use a full date-and-time stamp; it can get close to the ceiling quickly. Small, steady increments last forever:

defaultConfig {
    versionCode = 1        // 1, 2, 3 ... one more for every upload
    versionName = "1.0.0"  // major.minor.patch, for humans
}

Checklist before the first upload

• applicationId is yours, not com.example, and follows the naming rules
• Upload key created: RSA 2048 or more, valid 25 years or more
• Keystore stored outside the repo and backed up in two places
• Passwords in a password manager; keystore.properties and *.jks in .gitignore
• ./gradlew bundleRelease produces app-release.aab
• The release variant installed and tested on a real phone (./gradlew installRelease)
• versionCode increased since the last upload

Go deeper: Ship Your First Android App

Most face shape tools work the same way: you upload a selfie to someone's server and get a verdict back. Some want an account first, a few put the answer behind a paywall, and almost none tell you why they picked "oval". Shape & Shade is a new Android app from Hartmann Studios that does the whole thing on your phone and shows its work.

How a scan works

Tap Find my face shape, fit your face in the oval and take a photo, or pick one you already have (the system Photo Picker, so the app needs no storage permission). On-device AI, Google's MediaPipe Face Landmarker, finds 478 points on your face. That model ships inside the app, so the scan doesn't need a server.

From those points the app measures four things: forehead width, cheekbone width, jaw width and face length. The face shape decision is plain math on those ratios, not a black box: the app compares your proportions with six reference shapes (oval, round, square, heart, diamond, oblong) and picks the closest one. If you're close to two, it says so, for example "between heart and oval".

What you get

• Your shape, with the reason. The measurement lines are drawn on your photo, with a "Why this shape" note in plain language, such as "Your forehead is wider than your jaw" and "Your chin is narrow".
• Guides for your shape. Hairstyles, glasses frames, brows, beard and contour ideas. The top three in each category are free.
• History. Your scans stay on your phone, and one tap in Settings deletes all of them.

Pro

Pro adds a Color Season scan (hold a white sheet of paper for white balance, in daylight; you get one of 12 seasons, a palette, and colors to skip), live drape (colors tinted under your chin on camera, two side by side), glasses try-on, the full guides, unlimited history and no ads. Color season is for fun and style ideas, not a rule.

What it never does

It never rates how you look. There are no beauty scores, no attractiveness numbers, and no guessing at age, ethnicity or gender. Face shape is an estimate from your measurements.

Privacy

Your selfie stays on your phone. There's no account and no upload. The free version shows ads (Google's consent form is in Settings, under Privacy choices).

Shape & Shade is coming soon to Google Play, free with ads, in 22 languages. Until the listing is live, the screenshots and the promo video are on the app's site: chartmann1590.github.io/shapeshade-site.

Shape & Shade: Face Shape: coming soon to Google Play

Backups fail in two ways. Loudly, when a job runs and reports an error. And quietly, when a job stops running at all: the timer was disabled during an upgrade, the node was off, the cron line was lost in a rebuild, the API key expired.

Loud failures are easy, because every backup tool can email you. Quiet failures need a different shape of alert, and they are the ones that catch people out.

The trap: alerting only on failure

A job that never runs never fails. An off-site rclone sync that stopped in February will not send a single error between then and the day you need it. Your inbox stays clean the whole time, and a clean inbox looks exactly like a healthy backup.

So the alert you need is not "something failed". It is "nothing succeeded recently". That takes three pieces: notifications for the loud failures, a dead-man's switch for the quiet ones, and a report that checks every guest is actually covered.

Step 1: route the loud failures to your phone

Since Proxmox VE 8.1 there is a proper notification system under Datacenter → Notifications. It has two parts.

• Targets are where notifications go: SMTP (your own mail account), Gotify, a generic webhook, or the local sendmail. A webhook to a self-hosted ntfy server pushes straight to your phone, which matters because email from a homelab tends to land in spam exactly when it counts.
• Matchers decide which events go to which target. The default matcher sends everything to the mail-to-root target. Add one for backups: match field type equals vzdump, severity error and warning, target: your phone. A second matcher can send info events to email if you like a morning receipt.

One setting is easy to miss: every backup job's Notification mode has to be set to the notification system, or the matchers never see it. On the command line that is:

vzdump --all 1 --exclude 900,901 --mode snapshot --compress zstd \
  --notification-mode notification-system

The older --mailto option still works, but it is deprecated; the notification system replaces it.

Proxmox Backup Server has the same system under Configuration → Notifications for its own verify, prune, GC and sync jobs. Wire the sync job's failures to the same phone target, because the sync job is your off-site copy.

Step 2: a dead-man's switch for the quiet failures

For "nothing succeeded recently", use a check that expects a ping. A dead-man's switch service such as healthchecks.io, or a self-hosted Uptime Kuma push monitor, gives you a URL. Your job pings it on success. If the pings stop, you get a message.

vzdump has hook scripts for exactly this. Add one line to /etc/vzdump.conf:

script: /usr/local/bin/vzdump-hook.sh

Then the hook itself:

#!/bin/bash
# vzdump calls this with the phase as $1
URL=https://hc-ping.com/your-uuid-here
case "$1" in
  job-end)   curl -fsS -m 10 --retry 3 "$URL" >/dev/null ;;
  job-abort) curl -fsS -m 10 --retry 3 "$URL/fail" >/dev/null ;;
esac
exit 0

A clean finish pings the check; an aborted job pings its /fail URL so you hear about it straight away.

Set the check's period to a day and its grace to a few hours. A night the job does not run, for any reason, becomes a phone notification by breakfast.

Do the same for everything else on a timer: the rclone sync (a && curl at the end of the cron line) and the database dump timer.

Step 3: a weekly report of each guest's newest backup

Hooks tell you a job ran. They do not tell you it covered every guest. A job built for a hand-picked list of guests keeps pinging happily while every VM you created after it goes unprotected.

So once a week, a script on the node lists the newest backup of every guest and complains about any older than two days:

#!/bin/bash
# newest backup per guest on a storage; flag any older than MAXAGE days
STORE=pbs01; MAXAGE=2; now=$(date +%s)
API=/nodes/$(hostname)/storage/$STORE/content
pvesh get $API --content backup --output-format json \
 | jq -r '.[] | "\(.vmid) \(.ctime)"' | sort -k1,1n -k2,2nr | sort -u -k1,1n \
 | while read -r vmid ctime; do
     age=$(( (now - ctime) / 86400 ))
     [ "$age" -gt "$MAXAGE" ] && echo "STALE: guest $vmid, last backup ${age}d"
   done
ids="$(qm list | awk 'NR>1{print $1}') $(pct list | awk 'NR>1{print $1}')"
for id in $ids; do
  pvesh get $API --content backup --vmid "$id" --output-format json \
    | jq -e 'length > 0' >/dev/null || echo "NONE: guest $id has no backup"
done

Change STORE to your backup storage's name. Send the output to ntfy or email only when it is not empty, so a quiet week stays quiet.

The second loop is the important one. It catches a guest that has never been backed up at all, which is exactly the gap a hand-picked job list leaves.

Step 4: let Home Assistant watch its own backups

Home Assistant's Backup integration exposes sensors for the backup manager's state and the last successful automatic backup. An automation that fires when the last success is more than two days old closes the loop for the one system in the house that already knows how to notify your phone:

alias: Backup is stale
triggers:
  - trigger: time
    at: "09:00:00"
conditions:
  - condition: template
    value_template: >
      {% set last = states('sensor.backup_last_successful_automatic_backup') %}
      {{ (now() - last | as_datetime) > timedelta(days=2) }}
actions:
  - action: notify.mobile_app_your_phone
    data:
      message: "Home Assistant has not completed a backup in over two days."

Check the sensor's exact entity ID in Developer Tools → States. The Backup integration creates it once automatic backups are configured.

Step 5: watch the disk before it fails the job

Backup storage filling up is a backup failure in waiting, and a common cause of failed jobs. Proxmox shows storage usage on the Datacenter summary; PBS shows datastore usage and has its own notification for it.

A simple rule: when the backup target passes 80 percent, either prune harder or add a disk, and do it that week.

Step 6: break something on purpose

An alert you have never seen fire is in the same category as a backup you have never restored. Test every path once:

• Disable the backup job for a day and confirm the dead-man's switch fires.
• Point rclone at a bucket name that does not exist and confirm you hear about it.

If nothing arrives, fix the alert before you trust anything else in this post.

Checklist: monitoring

• Notification targets set up (phone push plus email), with a matcher for vzdump warnings and errors
• Every backup job on the notification system, on Proxmox and on PBS
• A dead-man's switch pinged by the vzdump hook, the rclone sync and the database dump timer
• A weekly backup-age report that also lists guests with no backup at all
• A Home Assistant automation that complains when its own backup is stale
• Backup storage usage watched, with 80 percent as the act-now line
• Every alert path deliberately triggered once

Go deeper: Never Lose Your Data

Using a typical voice assistant means accepting a trade. To get answers, your voice is recorded and sent to a server, processed there, and often kept. If you run a homelab, that kind of trade is probably what pushed you toward self-hosting in the first place. Aria is a voice assistant built the other way around: the listening, the thinking and the talking all happen on your Android device.

What runs on the phone

According to the listing, Aria does all of this locally:

• Speech recognition, turning what you say into text.
• Wake-word detection, so it can listen for its trigger without streaming audio anywhere.
• Language model inference, the part that actually understands and answers your request.
• Voice synthesis, for spoken replies.
• Translation, also handled on the device.
• Text-to-speech in multiple languages.

The key line is that there is no cloud LLM. Many assistants that call themselves private still send the actual request to a hosted model. Aria's listing says it does not, and that your voice is not uploaded. Conversation history stays local, and no account is required.

Optional features, and what they need

Some useful things an assistant can do require more than a microphone. Aria treats those as opt-in. The listing names:

• Web search, with visible source cards so you can see where an answer came from.
• Notification access, for smart replies.
• Phone, contacts, calendar, camera and location access.

Permissions are requested only when you use the feature that needs them. If you never turn on web search, Aria never needs to reach the web for it. If you never ask it to deal with your calendar, it never asks for calendar access.

That approach is worth understanding before you start. The core assistant works offline and on the device. The extras are there when you want them, and each one comes with its own permission prompt at the moment you first use it, rather than a long list of grants on install.

Web search with sources

The web search option is the one feature that, by nature, has to touch the internet. The listing's detail here is the source cards: when Aria uses search, the sources are shown, so you are not left guessing whether an answer came from the model or from a page.

Why on-device matters

The listing puts the case simply: most assistants send your voice and data to the cloud, and Aria keeps everything on your device. In practice that means:

• Nothing you say has to leave the phone for the assistant to work.
• It keeps working in places with no connection.
• There is no account tying your history to an identity on a server.

Good to know

• Price: free to download. The app contains ads, and the Play listing notes in-app purchases.
• Category: Tools, rated Everyone.
• Offline by default: the core features run without a network; web search is the opt-in exception.
• Permissions on demand: phone, contacts, calendar, camera, location and notification access are only requested when you use a feature that needs them.

Is it for you?

• You want a voice assistant but do not want your voice uploaded.
• You spend time somewhere offline, or you travel often.
• You want to decide feature by feature what an assistant can access.
• You want search answers to show their sources.

Get Aria: On-Device Assistant on Google Play

The Homelab the Right Way merch store is open. Thirteen items, all printed or embroidered to order, each one built around a running joke or a rule from the books. The video above is a one-minute review of the real products (the host is an AI-generated character; the product shots are the store's own).

Tees

• There's No Place Like 127.0.0.1: the house, the loopback address and a "Homelab · the right way" underline. If you know, you know.
• 3-2-1 or It Didn't Happen: three copies, two kinds of media, one off-site. The backup rule from Never Lose Your Data, on a shirt.
• Homelab the Right Way Crest: the channel crest.
• Turtle Ops: for the smart turtle tank build.

Hoodies

• sudo fix-everything: a terminal line for the command everyone wishes existed.
• Rack Stack: a rack diagram across the chest.

Hats

Three hats, all embroidered rather than printed: the >homelab. dad hat, the 127.0.0.1 snapback and the Right Way turtle beanie.

Desk and wall

• It's Always DNS mug, 11 oz. Because it is.
• Network map desk mat, 12 x 22 inches, a full-bleed navy network map with the title along the edge.
• The 3-2-1 Backup Rule poster, 18 x 24 inches.
• Turtle Ops sticker, 4 x 4 inches, for a laptop lid or a rack door.

How ordering works

Everything is made on demand by Printful and shipped from their facilities, so there is no stock to run out of and each item is printed when you order it. Sizes, colors and current prices are on each product page. The full list with photos is on the merch page, and the store link is in the link tree.

Go deeper: Homelab the Right Way

The DS18B20 is the easy sensor in a water-quality monitor. It is a waterproof stainless probe, the probe and its cable can go fully underwater, and it is accurate to ±0.5 °C out of the box with no calibration maths. So when the tank card suddenly says the water is 85 °C, or -127 °C, it is tempting to blame the probe, the board or the tank heater.

None of those is the cause. Both numbers are the sensor telling you it has no reading. This post covers what each one means, how the Smart Turtle Tank firmware keeps them off your graphs, and where to look when the probe will not stop saying 85.

The trap: two numbers that look like readings

The DS18B20 is a digital sensor. It talks over a single wire using a protocol called 1-Wire and sends the temperature as a number rather than as a voltage. That is why it is the accurate one, and also why it can hand you a perfectly formatted number that has nothing to do with the water.

There are two of these:

Neither is a temperature. If your code passes them through, the server stores them like any other reading, and your graph and alerts treat them as real. The book's alert rule fires when the water goes under 73 °F or over 85 °F, so a fake 85 °C sails straight past the upper limit and sets off an alert for water that is fine.

The fix in the firmware

The Smart Turtle Tank firmware reads the probe once per sample with the OneWire and DallasTemperature libraries (in platformio.ini they are paulstoffregen/OneWire and milesburton/DallasTemperature). The probe sits on D4:

#define TEMP_PIN D4        // GPIO6, DS18B20 DAT (adapter has the pull-up)

And this is the part of the sample loop that does the rejecting:

temp.requestTemperatures();        // ~750 ms at 12-bit
float t = temp.getTempCByIndex(0);
if (t > -100 && t != 85.0f) { accT += t; nT++; } // drop -127 and 85

Line by line:

• temp.requestTemperatures() tells the DS18B20 to measure. At 12-bit resolution that takes about 750 ms, and the call waits for it.
• getTempCByIndex(0) reads the first (and only) probe on the wire.
• The if throws away -127 (no probe) and exactly 85.0 (the power-on value), and counts only good reads in nT.

Every five minutes (ten samples) the firmware averages the good samples into one reading. When there were none, the temperature field is sent as null. A null on the graph is honest; a fake 85 °C would page you.

The server backs this up. Its validation accepts t only as null or between -5 and 50 °C, so anything else is rejected with a 400 and never reaches history.

The fix in ESPHome

If you would rather run the probe through ESPHome and Home Assistant, the same rejection is two filter lines on the dallas_temp sensor:

one_wire:
  - platform: gpio
    pin: GPIO6            # XIAO D4

sensor:
  - platform: dallas_temp
    name: "Tank water temperature"
    update_interval: 30s
    filters:
      - filter_out: 85.0
      - filter_out: -127.0

one_wire: sets up the 1-Wire bus on GPIO6, which is the XIAO's D4, and the dallas_temp sensor finds the probe on it. The two filter_out lines drop the 85 °C power-on value and the -127 °C unplugged value, the same job the PlatformIO firmware does.

Stuck at 85: check the wiring, not the code

Filtering keeps the bad values off the graph, but it does not fix them. If the temperature field stays null, or the raw value keeps coming back as 85 or -127, the sensor is not getting a clean read. The book's troubleshooting puts it plainly: an 85 °C reading usually means a loose DAT wire.

The probe has three wires that screw into a small adapter board, matched by the printed letters:

• Red to VCC
• Yellow to DAT
• Black to GND

Then three jumpers connect the adapter to the XIAO:

• The + rail (3V3) to the adapter's VCC pin.
• The - rail (GND) to the adapter's GND pin.
• XIAO D4 to the adapter's DAT pin.

Two details catch people here. First, the pins on your adapter may be in a different order than any picture you are following, so go by the printed letters, not by position. Second, the adapter belongs on 3V3, not 5V. Its VCC comes from the + rail, which is fed by the XIAO's 3V3 pin, so the signal on DAT stays under the 3.3 V the XIAO's pins can take.

You also do not need to add a resistor. The DS18B20 needs a 4.7 kΩ pull-up on its data line, and the kit's adapter board already has it built in.

Once the probe reads, the only adjustment left is a one-time offset. Put the DS18B20 and a reference aquarium thermometer in the same cup of water for five minutes; the difference is temp_offset_c, a setting on the server. Expect a few tenths of a degree, since the probe is rated ±0.5 °C.

Checklist

• Probe wires screwed into the adapter by letter: red to VCC, yellow to DAT, black to GND, each one tugged gently.
• Adapter VCC from the 3V3 (+) rail, GND from the - rail, DAT to XIAO D4.
• No extra pull-up resistor; the adapter has the 4.7 kΩ one.
• Only the metal probe and its cable go in the water. The adapter board stays dry, with the cable hanging in a U-shaped drip loop below the electronics.
• Firmware drops -127 and exactly 85.0 and sends null when there was no good read.
• In ESPHome, filter_out: 85.0 and filter_out: -127.0 are on the dallas_temp sensor.
• Still null or stuck at 85? Re-seat the DAT, VCC and GND wires and confirm the adapter is on 3V3.
• Probe reading for real? Set temp_offset_c once against a reference thermometer.

Go deeper: Smart Turtle Tank

The store has a second series today: Android the Right Way, five practical ebooks on building Android apps and getting them onto Google Play. They sit alongside the six Homelab the Right Way books, and they are written the same way: short chapters, real code, diagrams instead of walls of text, and a checklist at the end.

The author ships Android apps on Google Play as Hartmann Studios, and the books use real, public examples from those apps where they help (the apps page lists them). Every version number, limit and deadline in the series was checked against Google's official pages in October 2026, and the books name the page.

Each book is a PDF and EPUB, $19, and each one has a free sample: the cover, the full table of contents and one complete chapter.

Which one to start with

• New to Android, or never published an app: start with Book 1.
• You can build screens but Compose keeps surprising you: Book 2.
• Your app exists and Play Console keeps saying no: Book 3.
• It's live and you want it to pay for itself: Book 4.
• You want AI features without a cloud bill: Book 5, which ends with an Android client for your own Ollama server at home.

Book 1: Ship Your First Android App

From Empty Project to Google Play: Android Studio, Kotlin, Signing, Testing Tracks and Your First Release

From an empty Android Studio project to a real app live on Google Play: setup, a first Kotlin + Compose app, the decisions you can't undo, a signed release build, Play Console and the 12-tester closed test.

Who it's for: You have an app idea, or a project that runs on your phone, and you want it live on Google Play.

62 pages, 23 diagrams. The free sample is all of Chapter 7, "Testing Tracks and the 12-Tester Rule".

Get the book · Read the free sample

Book 2: Compose Without the Confusion

Kotlin and Jetpack Compose Fundamentals: State, Layouts, Navigation, ViewModels and Room

Kotlin and Jetpack Compose that make sense: state and recomposition, layouts that behave, Material 3, Navigation 3, ViewModels with StateFlow, and Room.

Who it's for: You write Compose screens but state, recomposition and ViewModels still feel like guesswork.

67 pages, 25 diagrams. The free sample is all of Chapter 4, "State Without the Confusion".

Get the book · Read the free sample

Book 3: Pass Google Play Review

Target SDK, 16 KB Pages, Data Safety, Permissions and Automated Releases Without Rejections

Get an Android app through Google Play review and keep it there: target API 36, 16 KB page size, sensitive permissions, Data safety and account deletion, honest listings and vitals.

Who it's for: You publish on Google Play and want releases to stop getting rejected or blocked.

59 pages, 25 diagrams. The free sample is all of Chapter 3, "16 KB Page Size".

Get the book · Read the free sample

Book 4: Get Paid for Your Android App

AdMob, Consent, Play Billing Subscriptions and Store Listings That Convert, Done Honestly

The money side of an Android app done honestly: the right business model, AdMob with consent first, Play Billing from connection to acknowledgement, subscriptions, and listings that convert without overpromising.

Who it's for: Your app is live and you want it to earn something without tricking users or breaking Google's rules.

62 pages, 24 diagrams. The free sample is all of Chapter 5, "Play Billing Fundamentals".

Get the book · Read the free sample

Book 5: On-Device AI for Android

ML Kit, Local LLMs and Your Own Homelab AI Server in Kotlin Apps

Real AI features in a Kotlin app without sending everything to someone else's cloud: ML Kit, Gemini Nano, LiteRT, a local LLM on the phone, and a streaming chat with your own Ollama server.

Who it's for: You want AI features in a Kotlin app that run on the phone or on your own server, not someone else's cloud.

60 pages, 23 diagrams. The free sample is all of Chapter 7, "Your Homelab AI Server".

Get the book · Read the free sample

What every book includes

• Chapter-opener graphics and diagrams for the ideas that are easier to see than read
• Code in current Kotlin and Jetpack Compose
• A checklist and a cheat sheet
• PDF and EPUB

The free samples are the quickest way to see whether the style fits you. Over the next five days the blog has one post from each book, starting tomorrow with the two decisions you can't undo before your first Google Play upload.

Go deeper: Ship Your First Android App

Most AI image generators work the same way: you type a prompt, it goes to a server, and a picture comes back. That means an account, a connection, and your prompts sitting on somebody else's machine. PixelDream takes the other route. The models run on your phone, so once setup is done you can create images with no Wi-Fi, no mobile data and no account.

What it does

• Text to image, on the device. Describe what you are imagining, tap Create, and a local image model renders it using your phone's own hardware.
• Optional prompt enhancement. An on-device AI can expand a short idea into a richer prompt before rendering, so you do not need prompt-engineering experience. You can switch this off.
• Works anywhere. After the one-time setup download, generation needs no network, which the listing pitches for planes and off-grid use.
• A private local gallery. Every image is saved on the device, where you can revisit, export or share it when you choose.
• Quality and size controls. Pick generation quality and image size to trade detail against speed.
• Safety checks. On-device checks run before and after prompt enhancement to steer away from harmful content, and there is an in-app report option.

How it works

The listing breaks it into three steps:

1. Describe your idea in a sentence or two.
2. PixelDream optionally expands it into a fuller visual prompt, then a local diffusion model renders the image on your phone.
3. The finished image lands in your private gallery, ready to view, export or share.

The prompt expansion is the part that makes it approachable. A one-line idea is often too thin for a diffusion model to do much with, and the on-device language model fills in the visual detail for you before the image model runs.

What your phone needs

Running image models locally is demanding, and the listing is specific about hardware. Check this before you install:

The models total roughly 4.1 GB and download once over Wi-Fi during setup. The listing notes that older or lower-spec devices may run slowly or may not be supported.

Privacy

Image generation runs entirely on the device, and nothing about what you type or create is uploaded as part of making an image. Your prompts and pictures stay on the phone unless you choose to share them.

The listing is also clear about the exceptions: some diagnostics and the optional in-app feedback and bug-report tool use the network. Image generation itself does not.

Good to know

• Price: free to download, with optional ads and an optional ad-free upgrade (an in-app purchase).
• Content filtering: the on-device checks try to steer prompts and results away from harmful content, but the listing states plainly that no filter is perfect. Use it responsibly and report anything that slips through.
• Problems: bugs can be reported from Settings, then Report a Problem.
• Setup download: plan for a 4.1 GB download on Wi-Fi before first use.

Is it for you?

• You want to make AI images without an account or a subscription service.
• You want your prompts and images to stay on your own phone.
• You want something that works on a plane or with no signal.
• Your phone meets the RAM, storage and processor requirements above.

Get PixelDream: Offline AI Images on Google Play

Two Proxmox nodes feel like redundancy. One box dies, the other carries on. That is the picture most people have when they join a second machine to the cluster.

Out of the box, it is the opposite: two machines that can each stop the other from working. This post covers why that happens, the small fix that solves it, and the two related traps that make a cluster look haunted.

How quorum works, in one paragraph

A Proxmox cluster uses Corosync to agree on who is alive. Each node gets one vote, and the cluster is quorate when more than half the votes are present. Without quorum, the cluster filesystem at /etc/pve goes read-only. You can't start guests, change configs or create backups, and nothing in the UI saves.

The trap: 1 vote out of 2 is not a majority

Now do the arithmetic for two nodes. Lose either one, and the survivor holds 1 vote out of 2. That is exactly half, and half is not more than half. So the survivor freezes.

That is the part that catches people. The node that is still up, still powered and still on the network is the one that stops working, because it has no way to know whether the other node is dead or just unreachable. Refusing to write is the safe choice for the cluster, and it is a very annoying choice for you.

You can see the vote count at any time:

pvecm status

The fix: a third vote that isn't a third server

A QDevice is a tiny external voter. It can run on a Raspberry Pi, a NAS container or any always-on Linux box that isn't one of the cluster nodes. It gives the cluster a third vote without a third hypervisor.

With three votes, losing one node leaves 2 out of 3. That is more than half, so the survivor stays quorate and keeps working.

The setup is three installs and one command:

# On the external box (Debian/Ubuntu/Raspberry Pi OS):
apt install corosync-qnetd

# On EVERY cluster node:
apt install corosync-qdevice

# On ONE cluster node (root SSH to the QDevice box must work):
pvecm qdevice setup 192.168.10.5

# Check: you should see 3 total votes and "Qdevice" listed
pvecm status

Replace 192.168.10.5 with the address of your own external box.

Where the QDevice must not live

Don't run the QDevice as a VM or container on one of the cluster nodes. It is tempting, because the hardware is already there. But if that node goes down, it takes its own vote and the QDevice's vote with it, and you are back to 1 vote out of 3 on the survivor. Separate hardware is the whole point.

The related trap: a node on Wi-Fi that keeps flapping

Even with enough votes, a cluster can look broken if one member keeps dropping in and out. The usual cause is Wi-Fi.

Corosync is extremely sensitive to latency and jitter. It wants a stable, low-latency link: single-digit milliseconds, consistently. Wi-Fi delivers great average speeds and terrible consistency. A microwave, a neighbor's channel change or a roaming decision adds 50 to 300 ms of jitter for a few seconds. Corosync sees missed tokens, decides the node is gone, and the cluster reshuffles. A few seconds later it is back. Then it is gone again.

The symptoms look random:

• The node shows a red X, then turns green again
• /etc/pve is briefly read-only
• Backup jobs fail with "cluster not ready"
• The logs fill with lines like [TOTEM] A processor failed, forming new configuration

Check for it:

journalctl -u corosync --since "24 hours ago" | \
  grep -Ei "failed|new membership|retransmit"
corosync-cfgtool -s        # link status per node
ping -c 100 -i 0.2 <other-node> | tail -2   # look at mdev/max, not avg

Look at the mdev and max numbers from the ping, not the average. A good average with a big max is exactly the jitter Corosync hates.

The fix isn't a Corosync tuning trick. It's a cable. If the node physically can't be wired, use a powerline or MoCA adapter (still better than Wi-Fi), or take it out of the cluster and run it standalone. A standalone node you manage separately is far less trouble than a cluster member that drops out twice an hour.

If your nodes have two network ports, give Corosync a second link (link1) on a separate network or a direct cable between the nodes. Corosync fails over between links automatically.

When you're stuck without quorum right now

If one node of two is dead and you need the survivor working immediately, there is an emergency lever:

pvecm expected 1

This tells the survivor to accept being alone. It is an emergency lever, not a fix. Only use it when you are sure the other node is truly off, because two nodes that each think they are the whole cluster can write conflicting configs. Once the crisis is over, the real fix is still the QDevice.

Scripts: wait for quorum instead of failing halfway

If you script changes on a cluster with a flaky member, check quorum before each write and retry, instead of letting the script die partway through a batch:

until pvecm status | grep -q "Quorate:.*Yes"; do
  echo "waiting for quorum..."; sleep 10
done
pct destroy 123 --purge

The loop waits until pvecm status reports the cluster as quorate, then runs the write. Wrap each destructive or config-changing step this way and a brief membership blip costs you a pause, not a half-finished job.

Checklist

• Every cluster node is wired, ideally on the same switch
• Two-node clusters have a QDevice on separate hardware, never on a cluster node
• pvecm status shows the expected vote count (3 for two nodes plus a QDevice)
• Corosync logs show no membership changes over the past day
• Nodes with two ports give Corosync a second link (link1)
• Scripts check for quorum before each write
• You know the pvecm expected 1 lever, and when not to pull it

Go deeper: Homelab the Right Way

Book 6 in the series is out today: Automations That Just Work: Reliable Home Assistant with Zigbee, Z-Wave, Dashboards and Updates That Don't Break Things. It is 56 pages and 23 diagrams on the second six months of a Home Assistant install, the part where the magic has worn off and the family has stopped trusting the house.

The free sample is the whole of Chapter 4, the automations chapter. Here is a taste of what is in it, plus the Zigbee fix from Chapter 2 that most people need first.

The trap: a motion light that turns off while you are still there

The usual motion light has a motion trigger, a "turn on", a fixed two-minute delay, and a "turn off". It works most nights. Then someone stands still in the hallway reading a label and the light goes out on them.

The reason is the automation's mode. The default, single, means that when motion fires again while the first run is still waiting out its delay, the second trigger is silently dropped (there is a warning in the log, which nobody reads). The countdown that started on the first motion keeps running, and the light goes off two minutes after the first movement, not the last.

The fix: restart and a wait, not a delay

Two changes. Set the mode to restart, so fresh motion cancels the running countdown and starts over. And wait for the sensor to be off for two minutes instead of sleeping for two minutes:

alias: Hallway light on motion
description: On with motion after dark; off 2 min after motion stops
mode: restart
triggers:
  - trigger: state
    entity_id: binary_sensor.hallway_motion
    to: "on"
conditions:
  - condition: state
    entity_id: sun.sun
    state: below_horizon
actions:
  - action: light.turn_on
    target:
      entity_id: light.hallway_ceiling
    data:
      brightness_pct: 60
  - wait_for_trigger:
      - trigger: state
        entity_id: binary_sensor.hallway_motion
        to: "off"
        for: "00:02:00"
  - action: light.turn_off
    target:
      entity_id: light.hallway_ceiling

Every new motion restarts the run, so the light only goes off two minutes after the last movement ends. The for: on the wait also absorbs a sensor that flaps on and off within a second.

Three more rules from the chapter that keep automations readable:

• Every state trigger gets a to:. Without it, the automation fires on any change, including attribute updates like brightness or last_seen, and runs twenty times an hour.
• Flappy sensors get for: on the trigger. A door that reports open, closed, open within a second fires three times without it and zero times with for: "00:00:05".
• When an automation "didn't work", read its trace (Settings, Automations & Scenes, the automation, three-dot menu, Traces) before changing anything. It shows which trigger fired, what every condition evaluated to, and what each action did. Guessing is slower than reading.

The Zigbee fix that comes first

Most "the bedroom sensor dropped again" problems are not the sensor. They are the coordinator stick plugged straight into a USB 3.0 port on the server, inside a metal case, next to the access point. USB 3.0 ports and cables radiate noise in the 2.4 GHz band, which is exactly where Zigbee lives.

The fix is a USB 2.0 extension cable, one to two metres long, with the stick on the end of it, a metre away from any SSD, hub or access point. If the machine has a USB 2.0 port, use that. This single change fixes more Zigbee networks than any setting. The chapter goes on to the channel choice (Zigbee 15, 20 or 25, between Wi-Fi channels 1, 6 and 11, chosen before pairing anything), why battery sensors never route and a mains plug in each room is the mesh, and pairing devices in the room they will live in.

What the book covers

1. A home that works when the internet doesn't: the five-minute WAN unplug test, one naming scheme, areas and labels
2. Zigbee that stays up: coordinator choice and placement, channels, ZHA or Zigbee2MQTT, routers, a working Zigbee2MQTT configuration
3. Z-Wave without the mystery: 800-series controllers, Z-Wave JS UI, S2 inclusion, node statistics instead of nightly heals
4. Automations that mean something: triggers, conditions, modes, the motion light, traces (the free sample chapter)
5. Helpers, templates and blueprints: house mode and guest mode, template sensors with defaults, a motion-light blueprint
6. Dashboards people actually use: phone, wall tablet and admin; Sections and tiles; conditional cards
7. Notifications that don't cry wolf: tags, actionable alerts, one daily battery report, quiet hours, the alert integration
8. Updates without breaking things: the monthly routine, backup plus Proxmox snapshot, one layer at a time, three ways back

Plus the Weekend Reliability Checklist and a cheat sheet. PDF and EPUB, with the full automations chapter free below.

Checklist

• Motion lights on mode: restart with a wait_for_trigger, not a fixed delay
• Every state trigger has a to:; flappy sensors have for:
• Coordinator on a USB 2.0 extension cable, away from the case and the access point
• Zigbee on channel 15, 20 or 25, set before pairing
• A mains-powered router in each room between the coordinator and the far sensors

Go deeper: Automations That Just Work

Grocy is a self-hosted tool for tracking what is in your kitchen: stock levels, expiration dates, shopping lists. It is a good fit for a homelab, but it has one weak spot, and anyone who has tried it knows what it is. Keeping it accurate means entering items by hand, and once you fall behind, the inventory stops matching the fridge and the whole system quietly loses its value.

Grocy Fridge Scanner goes after that manual step. You take a photo of your fridge or pantry, an AI model running on your phone identifies what is there, and the app updates your Grocy stock.

What it does

• Photo scanning. Snap the fridge or pantry, and the on-device model identifies the items in the picture.
• Automatic counting. Stock levels are counted from the photo instead of typed in.
• Expiration tracking. The app tracks expiration dates so you know what needs using first.
• Direct Grocy integration. Updates go straight into your Grocy instance, with real-time inventory sync.
• Shopping lists. It can generate a shopping list from what you have and what you are missing.
• Less waste. Knowing what is about to expire is the point, and the listing frames the app around reducing food waste.

How it fits into a Grocy setup

The app sits between your kitchen and the Grocy instance you already run. Instead of opening Grocy and adjusting each product, you take a photo and let the scanner do the identification and counting, then the stock in Grocy is updated for you. The listing's promise is that no manual entry is needed for those updates.

That changes the habit you need to keep the system accurate. Taking a quick photo after a shopping trip, or whenever you open the pantry to plan a meal, is a much smaller ask than typing in every item. A system that is easier to keep up is one that stays accurate, and an accurate Grocy is what makes the expiration tracking and shopping lists worth having.

Who the listing has in mind

The listing names four groups: Grocy users who want automation, anyone tired of manual inventory tracking, families managing household supplies, and minimalists who want to reduce waste. The common thread is that you want the benefits of an inventory without the chore of maintaining one.

Privacy

If you self-host Grocy, there is a good chance you chose it partly to keep household data off someone else's servers. The scanner keeps to the same idea. According to the listing:

• All processing happens on your device.
• Photos are not uploaded to the cloud.
• Your grocery data stays local.
• No account is required.

Because identification runs on the phone, the photo of the inside of your fridge does not need to go anywhere except into the model on your own device, and the resulting stock changes go to your own Grocy server.

Good to know

• Price: free to download, with an optional premium upgrade mentioned in the listing.
• Ads: the app contains ads.
• Category: Food and Drink, rated Everyone.
• You need Grocy: the app updates an existing Grocy inventory, so it assumes you already run Grocy or plan to.
• On-device AI: identification runs locally rather than through a cloud service.

Is it for you?

• You run Grocy and your stock levels are out of date more often than not.
• You want expiration dates tracked without logging every item by hand.
• You manage supplies for a household and want a shopping list built from what is actually there.
• You prefer that photos of your kitchen stay on your phone.

Get Grocy Fridge Scanner on Google Play

Templates are one of Proxmox's best features. You build a base image once, and new guests come off it in seconds. They are also one of its quietest traps, because they create dependencies you cannot see in the guest list, and those dependencies bite on the day you tidy up.

This post is about that day: what a template really is to the guests built from it, how to prove whether one is load-bearing, and how to retire one without breaking anything.

Full clones vs linked clones

When you clone a template, Proxmox offers two modes:

• Full clone: a complete, independent copy of the disk. Slower to create, uses more space, depends on nothing.
• Linked clone: a thin copy that stores only the differences from the template's disk. Instant, tiny, and permanently tied to the template's base disk.

That last part is the whole story. A linked clone is not a copy of the template. It is a layer of changes sitting on top of it. Take away the bottom layer and the top layer has nothing to stand on.

You can see the relationship in the disk names. A template's disks are named like base-9000-disk-0, and a linked clone's config refers to that base, like this:

local-lvm:base-9000-disk-0/vm-105-disk-0

Read it left to right: VM 105's disk lives on top of template 9000's base disk.

The trap: "it's stopped, so it's junk"

Templates are always stopped. In a list of guests, a template looks exactly like an abandoned VM.

There is a nastier version too. A plain stopped container that was converted to a template, then used as the source for linked clones, looks like any other forgotten container. Nothing about it shouts "other guests need me".

Delete that base, and what happens depends on your storage:

Either way, you find out at the worst possible moment. The rule of thumb from the book: never delete a template, or anything named base-*, until you have proven nothing references it.

The fix, part 1: find every dependent

Every guest config lives in /etc/pve, so one grep tells you who depends on a base. For template 9000:

# Who uses template 9000's disks?
grep -rl "base-9000-" /etc/pve/nodes/*/qemu-server/ /etc/pve/nodes/*/lxc/

If the grep returns anything other than the template's own config, the template is load-bearing. Leave it, label it, and move on.

To see every template on the cluster in the first place:

# All templates on the cluster
grep -l "^template: 1" /etc/pve/nodes/*/qemu-server/*.conf \
  /etc/pve/nodes/*/lxc/*.conf

The fix, part 2: label the load-bearing guests

The cheapest fix in the whole chapter is a note and a tag. Write it in the guest's Notes field (the Summary tab), and add a keep tag:

qm set 9000 --tags "template,keep" \
  --description "BASE TEMPLATE. Linked clones depend on this. Do not delete."
pct set 9050 --tags "template,keep"

Tags show up as colored pills in the resource tree. A bright red keep tag stops a lot of 1 a.m. mistakes, and the note tells whoever is cleaning up why the guest is there.

The same idea carries into any cleanup script. The book's backup-before-delete loop skips templates outright before it touches anything:

grep -q "^template: 1" /etc/pve/{lxc,qemu-server}/$id.conf 2>/dev/null && \
  { echo "SKIP $id: template"; continue; }

The fix, part 3: untangle before you retire

Sometimes you really do want a template gone: it is old, its OS is out of date, and you have built a better one. You can retire it, but only after its linked clones stop needing it. That means turning each linked clone into a full, independent guest first.

The simplest way is a fresh full clone of each linked clone:

# VM: full, independent copy of linked clone 105 as 305
qm clone 105 305 --full 1 --name app-server
# Container: same idea
pct clone 205 405 --full 1 --hostname app-ct

Moving a disk to a different storage also writes a full copy:

qm disk move 105 scsi0 other-store --delete 1

For containers, pct move-volume does the same job.

Then work through it in order:

1. Test the full clone.
2. Retire the linked one.
3. Rerun the dependents grep for that template.
4. When it comes back with nothing but the template's own config, the template is finally safe to remove.

Deleting it is still a cleanup like any other: back it up, verify the archive, then destroy with purge.

Long-lived guests should be full clones

Linked clones are instant and tiny, which makes them tempting. But the book's checklist is clear: long-lived production guests should be full clones, so they depend on nothing and a future cleanup cannot pull the floor out from under them.

And because templates stick around, keep them fresh: rebuild or update them on a schedule, with a patched OS and current cloud-init, so new guests do not start life months behind.

Checklist

• Every template is tagged keep, with a note saying what depends on it
• You have grepped for base-<id>- before deleting anything that might be a base
• Any cleanup script skips guests with template: 1 in their config
• Long-lived production guests are full clones, not linked clones
• Before retiring a template: full-clone (or disk-move) each linked clone, test it, retire the linked one, rerun the grep
• Templates are rebuilt or updated on a schedule (patched OS, current cloud-init)

Go deeper: Homelab the Right Way

Long drives have a way of going quiet in the wrong places. The scenery gets interesting right where the cell signal disappears, and most navigation and tour apps stop being useful at exactly that point. TrailSage is built around the opposite assumption: that you will be somewhere without coverage, and the app should keep working anyway.

It combines offline GPS navigation with an audio tour guide. The commentary is generated by an AI model that runs on the phone itself, so the stories about the places along your route do not depend on a connection or an account.

What it does

• Offline maps and navigation. You download maps ahead of time, then get turn-by-turn directions and live location tracking without cell service.
• AI audio tours. An on-device model generates commentary about points of interest along your route, including historical facts and local stories.
• A choice of voices. The narration comes with multiple voice options.
• Hands-off playback. Tours can start automatically when you drive, can be paused and resumed, and the narration adjusts to your speed.
• Trip planning. You can save favorite routes, customize the stops on a tour, share routes with friends, and import GPX files.
• A driving-friendly interface. The layout is clean, with large buttons and a night mode, and it runs on both phones and tablets.

How a trip with it works

The workflow follows from the feature list. Before you leave, while you still have a connection, you download the maps for the area you are heading into. From there the app does not need the internet: navigation, location tracking and the tour commentary all run on the device.

If you already have a route planned in another tool, the GPX import means you do not have to rebuild it. You can adjust which stops the tour covers, save the route for later, or share it with whoever you are travelling with.

Once you start driving, the auto-start option means the tour can begin without you touching the phone, and the speed-adjusted narration is meant to keep the commentary in step with how fast you are moving. If you stop for fuel or food, you pause and pick it back up later.

Why on-device AI matters here

Generating the tour commentary on the phone is what lets the audio guide work in the same dead zones as the offline maps. A cloud-based guide would go silent the moment the signal dropped. With TrailSage, the model is already on the device, so the stories keep coming.

Privacy

The listing is direct about this. All of the AI processing happens on the device. There is no cloud component and no account to create. Your routes stay on your phone, and the app states that it does no tracking and no data uploads.

For a travel app, that is a meaningful difference. Your route history is a fairly detailed record of where you go, and here it is not leaving the phone.

Good to know

• Price: free to download, with an optional premium upgrade mentioned in the listing.
• Ads: the app contains ads.
• Category: Travel and Local, rated Everyone.
• Battery: the app is described as battery-efficient, which matters on a long day of navigation.
• Prepare before you go: offline maps have to be downloaded before you lose service, so do that at home or at your last stop with a connection.

Is it for you?

• You take road trips through areas where cell coverage is patchy or missing.
• You want to learn something about the places you are driving past, without reading a screen.
• You prefer an app that works without an account and keeps your routes on your phone.
• You already plan routes elsewhere and want to bring them in as GPX files.
• You want a night mode and large buttons for use in the car.

Get TrailSage: AI Road Trip Guide on Google Play

Running a language model at home is a common homelab project now. Ollama makes it straightforward to host models on your own machine, but you still need a decent way to talk to that server when you are not sitting at your desk. Ollama AI Chat is an Android client for exactly that, and it adds a second mode: running smaller models directly on the phone, with no server at all.

Two ways to run a model

Remote Ollama. Point the app at your home or work Ollama server and you get access to whatever models it hosts. You can add multiple servers, switch models per conversation, and watch responses stream in real time.

On-device. The app can also run models locally through Google's LiteRT-LM runtime. The listing names Gemma 4, Gemma 3, Qwen 3, Qwen 2.5, DeepSeek R1 Distill and Phi-4 Mini, ranging from about 300 MB to about 4 GB depending on capability. You download a model once, and after that chatting works fully offline, with zero network traffic for chat content.

That split is practical. When you are on your home network, the big models on your server are available. When you are somewhere without a connection, a smaller model on the phone still works.

What it does

• Streaming chat for both remote and on-device models, with history saved locally.
• Thread organization: pin, archive and label conversations; export or share a whole thread as Markdown.
• Message tools: copy, share, delete, edit and resend, regenerate, and stop a response mid-stream while keeping what was already written.
• Search inside a conversation or across all of them, jumping straight to the message.
• Images for vision-capable remote models, compressed automatically before upload.
• Voice: speech-to-text input and read-aloud replies.
• Model control per thread: temperature, top_p, top_k, context window and seed, plus token speed and response time under each reply and full model details (parameters, quantization, template, license).

Web Chat Sync

The newest feature lets you keep chatting from a computer without installing anything on it. You turn on Web Sync in the app's settings and sign in with Google or an email and password. Then you open the web chat page in any desktop or mobile browser, sign in with the same account, and your threads appear.

The interesting part is where the work happens. When you type in the browser, your Android phone receives the message, runs the inference (against your Ollama server or on-device), and streams the answer back to the browser. If the phone is offline, messages queue in the browser and are sent once it reconnects. A presence indicator shows when the phone is online, and the model selector only lists models you have actually installed.

Privacy

Conversation history is stored locally on the device in a Room database. On-device inference sends no chat content over the network. If you turn on Web Sync, threads and messages sync to Firebase Realtime Database under your own account, secured by Firebase Auth, so that part does go through a cloud service. The listing also states there is no third-party advertising data collection for chat content.

Good to know

• Price: free to download. The app contains ads, and the Play listing notes in-app purchases.
• Requirements: Android 7.0 (API 24) or higher.
• Connection: remote Ollama and Web Chat Sync need an internet connection; on-device models work offline after the download.
• Storage: on-device models take roughly 300 MB to 4 GB each, so check your free space first.
• Open source: released under the MIT license.

Is it for you?

• You run an Ollama server and want a proper phone client for it.
• You want a model that still works on the phone with no connection.
• You compare models and care about settings like temperature, context window and token speed.
• You want to continue phone conversations from a browser without installing a desktop app.

Get Ollama AI Chat on Google Play

If you run OctoPrint, you know the routine: a print is going, you have walked away, and now you want to know whether the first layer stuck. Opening the web interface on a phone works, but it was not designed for a small screen. OctoPulse is a native Android companion for OctoPrint that puts the things you check most often (progress, temperatures, the camera) one tap away.

OctoPrint is the open-source web interface many people use to run a 3D printer from a Raspberry Pi or another small computer. OctoPulse talks to it over your network. It works with any printer running OctoPrint, including OctoPi on a Raspberry Pi, and the listing names Ender 3, Prusa and Bambu (with OctoPrint) as examples. The rule of thumb it gives is simple: if you can open OctoPrint in your browser, OctoPulse can connect.

What it does

• Finds your printer for you. It scans your Wi-Fi using mDNS/Bonjour, SSDP and a subnet scan, so you do not type IP addresses. It also verifies that what it found is really OctoPrint.
• Pairs without copying API keys. It uses OctoPrint's official Application Keys: tap the printer, approve the request in OctoPrint, and it is connected.
• Shows every printer on one dashboard. Status, progress percentage, time remaining, and nozzle and bed temperatures, with pull to refresh.
• Streams the camera. MJPEG or snapshot streaming, with flip, rotate and automatic reconnect.
• Gives you real control. Jog X, Y and Z, home the axes, extrude and retract, set temperatures, run the fan, hit emergency stop, or send G-code from a terminal.
• Previews G-code. A 2D and 3D layer viewer with pinch-zoom and orbit.
• Manages files. Browse what is on OctoPrint, see details, start a print or delete a file.
• Sends alerts. Notifications when a print finishes or fails, and at 25, 50, 75 and 90 percent, with per-printer toggles and background polling. It respects Do Not Disturb.

Getting started

The setup the listing describes is three steps:

1. Install OctoPulse and join the same Wi-Fi network as your OctoPrint server.
2. Tap Discover Printers on Wi-Fi, choose your printer, tap Pair, and approve the request inside OctoPrint.
3. From there you can monitor progress, watch the camera, pause or stop if needed, and start the next print.

For access away from home, OctoPulse does not provide its own cloud relay. Instead you point it at your VPN or reverse proxy URL, and OctoPrint has to be reachable that way.

Privacy and permissions

This is where OctoPulse fits a self-hosted setup well. There is no account and no sign-up. Print files, G-code and camera feeds do not go to the developer's servers; the data stays between your phone and your printer. Hosts, API keys and camera URLs are encrypted on the device, with the keys stored using the Android Keystore.

The permissions are limited to what the features need: network and Wi-Fi state, multicast for mDNS discovery, notifications for print alerts, starting at boot to reschedule alerts, vibration, and the advertising ID for ads. It does not request location, camera or contacts. Discovery scans your local subnet only.

Good to know

• Price: free, with no subscription.
• Ads: it contains ads, a small banner plus an occasional full-screen ad after setup steps. The listing says ads are never shown during a print.
• Open source: the app is released under the MIT license.
• Look and feel: dark theme, haptics and offline handling.
• Not official: OctoPulse is not affiliated with the OctoPrint project.

Is it for you?

• You already run OctoPrint, on a Raspberry Pi or another machine.
• You want progress, temps and the camera on your phone without opening a browser.
• You run more than one printer and want them on a single dashboard.
• You would rather keep printer data on your own network than in someone's cloud.
• You already have a VPN or reverse proxy if you want to check prints remotely.

Get OctoPulse: OctoPrint Companion on Google Play

Three copies of anything you care about, on two different kinds of storage, with one of them somewhere else. Everyone has heard the 3-2-1 rule. Far fewer homelabs actually have it, because the rule is easy to say and the details are where it falls apart.

The problem is usually not that people have no backups. It is that some of the copies they are counting are not copies at all.

Things that feel like backups but aren't

RAID or a ZFS mirror. That is one copy on resilient disks. It protects you from a dead drive and from nothing else: not from rm -rf, not from a bad update, not from ransomware, not from the host catching fire. Delete a file and the mirror faithfully deletes it on both disks.

Snapshots. A ZFS or Proxmox snapshot lives on the same pool as the data. It is a wonderful undo button and a terrible backup. Lose the pool and the snapshots go with it.

A second copy on the same box. vzdump writing to a different directory on the same host is one disk failure away from losing both copies.

The NAS. A copy on the NAS is a real second copy. It is still in the same house, on the same power circuit, behind the same door.

The cloud sync folder. Sync is not backup. Delete the file at home and the cloud deletes it too, sometimes with a short grace period, sometimes not.

What actually counts

A copy counts when it survives the loss of the thing it was copied from. That one sentence settles most arguments about what is and isn't a backup.

Two kinds of storage means two things that do not fail together: local disk and a NAS, local disk and object storage, a Proxmox Backup Server datastore and a tape if you are that kind of person.

Off-site means a different building. A friend's house across town is off-site. The garage is not.

A shape that satisfies the rule for a typical Proxmox homelab looks like this:

Notice that row 1 is in the table. The live data is a copy, it just is not a backup. RAID earns its place by keeping you running through a disk failure, not by protecting your history.

Write the inventory first

Before touching a single backup job, write down what you are protecting. It fits on one page and it is one of the most useful documents a homelab can have.

One row per thing, four columns:

1. What it is (Home Assistant VM, OPNsense, the photo server, the Proxmox hosts themselves, the NAS data share)
2. How it is backed up
3. How far back you can go
4. How you would restore it

The last column is the one that exposes the holes. It is easy to write "nightly backup" in column two. It is much harder to write a restore path you have actually tried. Any row with "none" in column two, or a restore path you have never tested, is your to-do list.

Keep the table somewhere that survives the homelab: a note on your phone or a printed page. A recovery plan stored only on the server you are recovering is not much of a plan.

Decide what you do not back up

Backing up everything is how backup storage fills up and jobs start failing. Some things are cheaper to rebuild than to store:

• Downloaded ISOs and container templates. Keep a list, not the files.
• Media libraries you can re-rip or re-download, if you are honest about whether you would.
• Scratch VMs and test containers. Tag them scratch so the exclude is obvious.
• Caches: transcodes, thumbnails an app will regenerate, package caches.

Everything not on that list gets backed up by default. "By default" is the important phrase: a backup job that protects new guests automatically, rather than a hand-picked list, is what makes it true.

Checklist

• Inventory written: one row per thing, with how it is backed up, how far back, and the restore path
• Every row has a copy on a second kind of storage and one off-site
• RAID, snapshots and sync folders are not counted as backups anywhere in the table
• A short list of what you deliberately do not back up, and why
• The table lives somewhere that survives the homelab

RAID keeps you running. Backups get you back. You want both, and you want to know which one you are looking at.

Go deeper: Never Lose Your Data

Your Proxmox backup job has a schedule, a storage target and a little green check. That check proves one thing: the job wrote some bytes somewhere. It does not prove every guest is covered, that the copy survives a dead host, or that anything actually restores.

This post walks through a complete homelab backup setup in the order you would build it, one layer at a time. Each layer closes a hole the previous one leaves open.

1. The plan: 3-2-1, honestly

Three copies of anything you care about, on two different kinds of storage, with one of them somewhere else.

A copy only counts if it survives the loss of the thing it was copied from. That rules out RAID and ZFS mirrors (one copy on resilient disks), snapshots (same pool as the data), a second copy on the same host, and sync folders (delete at home, delete in the cloud). The NAS is a real second copy, but it is still in the same house. Off-site means a different building.

Before touching any job, write a one-page inventory: each thing you run, how it is backed up, how far back you can go, and how you would restore it. The restore column is the one that exposes the gaps.

2. vzdump: the backup you already have

Every Proxmox install ships with vzdump. Point it at storage that is not the host's own disk, such as an NFS share on the NAS:

pvesm add nfs nas-backup --server 192.168.10.40 --export /volume1/proxmox \
  --content backup --options vers=4.1

Then create one job under Datacenter → Backup → Add with Selection mode: All and your scratch guests under Exclude, so every new guest is protected the day it is created. Snapshot mode, ZSTD compression, a nightly schedule and a notes template like {{guestname}} on {{node}}.

Install the QEMU guest agent in every VM and enable it in the VM's Options. With it, snapshot mode asks the guest to flush its filesystems first, which is the difference between a consistent backup and one that needs fsck on restore.

3. Proxmox Backup Server: when vzdump isn't enough

PBS adds deduplication, incremental backups, verify jobs and client-side encryption. The trap is running it on the same host, or in a VM on the same host with its datastore on the same pool. It works beautifully until the host dies, and then the backups die with it. Give PBS its own hardware, however modest: an old office PC with one large disk and 4 GB of RAM is plenty for a home datastore.

Connect it with a dedicated backup@pbs user rather than root, and turn on client-side encryption:

pvesm set pbs01 --encryption-key autogen

Every chunk is then encrypted before it leaves the node. Download that key immediately and store it somewhere that is not the cluster, such as a password manager or a printed QR code. Without the key, every encrypted backup is unrecoverable. Losing it is the one mistake with no undo.

Running both is a sensible shape: PBS nightly for everything, plus vzdump to the NAS for the few guests you want as single portable files.

4. Retention that lets you sleep

keep-daily=7 does not mean "keep seven days". It means "keep the last backup from each of the last seven days that have a backup". If the job failed for a month and then ran once, that one run can satisfy every keep rule at once, and pruning deletes the older history. The rules keep the newest backup per calendar bucket; they never promise coverage of time.

Retention also does not protect you from a bad backup: if the guest was already corrupted, you just have seven copies of the corruption. That is why weekly and monthly buckets matter. Set retention on the storage or the PBS prune job, not per job, check it in the prune simulator, and take a protected backup before every risky change so pruning cannot touch it.

5. Off-site: the copy that survives the house

Three realistic options: an encrypted copy in Backblaze B2 via rclone, a PBS sync job to a friend's box over Tailscale, or a USB disk rotated to work. The USB disk is cheap and fast to restore from, but it is not automatic, and that is its problem.

For B2, put an rclone crypt remote on top of the bucket with a key scoped to that bucket, sync the dump directory nightly with a bandwidth limit during the day, add a lifecycle rule so hidden versions expire, and run rclone check monthly. Store the two crypt passwords with your PBS key, outside the homelab. And read the current B2 price from Backblaze's own pricing page rather than from any guide, including this one.

The trap here is the off-site copy that was set up once and never checked: an expired app key, a friend's box that was powered off, a bucket that filled up. Off-site is where "no news is good news" does the most damage.

6. Restore testing: the only proof

"Verified" means different things at each layer. A job reporting OK means it finished writing. zstd -t means the archive is complete and decompresses. A PBS verify job means the chunks still match their hashes. None of them means the guest boots.

Once a quarter, run four drills, each restored to a new ID with the network unplugged, then destroyed:

1. A VM from PBS. Does it boot, and is last night's data there?
2. A container from a vzdump archive on the NAS (second tool, second storage).
3. A single file from PBS using File Restore. This is the restore you will do most often.
4. Something from off-site. This is the only drill that proves the copy that survives the house.

qmrestore pbs01:backup/vm/101/2026-10-08T01:30:00Z 9101 \
  --storage local-zfs --unique 1
qm set 9101 --net0 virtio,bridge=vmbr0,link_down=1
qm start 9101

Write each drill down: date, what, from where, result. A drill nobody wrote down did not happen.

7. Alerts for the jobs that quietly stop

Alerting only on failure has a blind spot: a job that never runs never fails. The alert you need is "nothing succeeded recently".

Use the Proxmox notification system (VE 8.1+) for warnings and errors, then add a dead-man's switch: a check URL, from a service like healthchecks.io or a self-hosted Uptime Kuma push monitor, that your job pings on success. vzdump's hook script makes it a few lines in /etc/vzdump.conf. Set the check's period to a day with a grace of a few hours, and a night the job does not run becomes a phone notification by breakfast. Do the same for the rclone sync.

Finally, a weekly backup-age report that lists the newest backup of every guest and flags any older than two days, or any guest with no backup at all. That catches the "selected VMs" trap no matter how it sneaks back in.

The short version

• An inventory with a tested restore path per row
• One vzdump or PBS job in Selection mode All, on storage that is not the host
• PBS on its own hardware, encrypted, key saved outside the cluster
• Retention you have actually checked in the simulator
• An off-site copy that is automatic and monitored
• Quarterly restore drills, written down
• A dead-man's switch, so silence becomes an alert

Go deeper: Never Lose Your Data

Open your Proxmox web UI, click your backup storage and sort by date. Is there a backup of every guest you care about from the last 48 hours? For a lot of homelabs the honest answer is "most of them", and "most" is how data gets lost.

A backup job in the Datacenter view looks reassuring. It has a schedule, a storage target and a little green check. That check proves one thing: the job wrote some bytes somewhere. It does not prove that every guest you care about is in there.

The trap: a job built for "selected VMs"

The most common way this goes wrong is the selection mode. Somebody (often past you) created the job for "selected VMs" when the homelab had five guests. Every guest built after that day is unprotected, and the job keeps reporting success every night, because the guests it knows about are fine.

Nothing errors. Nothing emails you. The list of protected guests and the list of running guests just drift apart, one new container at a time.

The fix: one job that covers everything

Make your main job cover all guests, and exclude the few you truly do not want. New guests are protected the day they are created. If you only make one change after reading this, make this one.

In the UI: Datacenter → Backup → Add, then:

• Selection mode: All, with scratch and test guests under Exclude.
• Mode: Snapshot for running guests. The guest keeps running. Stopped guests are backed up too; Proxmox just reads their disks, and the forgotten stopped VM is often the one you will want back.
• Compression: ZSTD. Fast and small.
• Schedule: nightly, at a time nobody is using anything, for example 02:30.
• Retention: "use storage defaults", so the numbers live in one place.
• Notes template: {{guestname}} on {{node}}, so the backup list is readable when a VM ID means nothing to you at 2 AM.

The same job from the command line, if you like to keep config in version control:

pvesh create /cluster/backup \
  --schedule "02:30" \
  --all 1 \
  --storage nas-backup \
  --mode snapshot \
  --compress zstd \
  --notes-template "{{guestname}} on {{node}}"

Need to leave out a scratch VM? Use --exclude 9001,9002 instead of switching back to selected guests. An exclude list fails safe; an include list fails dangerous. If you forget to update an exclude list, you back up one guest too many. If you forget to update an include list, you lose a guest.

Three other things hiding behind the green check

The selection mode is the big one, but it is not the only way a "working" job quietly stops protecting you.

1. The storage silently isn't there

If your NAS is added as a plain Directory storage on a path you mounted yourself, and that mount fails at boot, Proxmox will happily write backups into the empty folder on your root disk. A night or two later the host's root filesystem is full and things break in confusing ways.

Either use the native NFS storage type, which lets Proxmox manage the mount and mark the storage offline if it fails, or tell Proxmox the path must be a mountpoint:

pvesm set nas-backup --is_mountpoint yes

And check before you trust it:

pvesm status                 # every storage should say "active"
df -h /mnt/pve/nas-backup    # should show the NAS size, not the root disk

2. Nobody gets told

By default, failures go to the root mailbox on the host, which nobody reads. Proxmox VE 8.1 and later has a proper notification system under Datacenter → Notifications. Add a target you actually read, point backup events at it, and set the job's notification mode to use it. Then test it on purpose:

vzdump 101 --storage does-not-exist

If no alert arrives, fix that before anything else. A weekly "all good" message is worth having too: silence is ambiguous, and a success message that suddenly stops arriving is a signal.

3. Nothing gets pruned

Without retention, the backup share fills up and every job after that fails. Set retention on the storage itself so every job that writes there inherits it:

pvesm set nas-backup \
  --prune-backups keep-last=2,keep-daily=7,keep-weekly=4,keep-monthly=3

Those numbers do not mean what most people think they mean. That is a post of its own.

Prove it: a backup you haven't restored is a rumor

A green check says the job finished writing. A quick integrity check says the archive is readable end to end:

zstd -t /mnt/pve/nas-backup/dump/vzdump-qemu-101-*.vma.zst

Only a restore proves the guest actually comes back. Restore to a spare ID, with the network disconnected so it does not fight the original for an IP, boot it, look around, then destroy the test copy:

qmrestore /mnt/pve/nas-backup/dump/vzdump-qemu-101-<date>.vma.zst 9101 \
  --storage local-zfs --unique 1

--unique gives the restored VM fresh MAC addresses so it can sit next to the original.

Checklist

• One backup job set to All guests (with excludes), not a hand-picked list
• Backup storage is native NFS or PBS, or has is_mountpoint set
• Retention set on the storage
• Failure notifications reach somewhere you actually read, and you have tested them
• The newest backup of every guest is less than 48 hours old
• One test restore done, to a new ID, and written down with the date

Five minutes in the Datacenter view now is a lot cheaper than finding out during a restore that the VM you need was never in the job.

Go deeper: Never Lose Your Data

A water-quality monitor for an aquarium or turtle tank is a great first ESP32 project: a temperature probe, a TDS probe and a turbidity (water clarity) sensor, all reporting into Home Assistant. Two of those three sensors are easy. The third one has a wire that can kill the board if it goes in the wrong place.

This walkthrough uses the Seeed XIAO ESP32-C3, the board used in the Smart Turtle Tank build, but the rule applies to any 3.3 V microcontroller.

The rule that keeps the board alive

Two voltages come out of the XIAO:

• 5V is the USB supply passed straight through.
• 3V3 is regulated down for the chip.

The chip's pins can only take 3.3 V on their inputs. So the rule is simple: a sensor's power can come from 5V if it needs it, but anything that goes back into a D pin must be at or under 3.3 V.

The DS18B20 temperature probe and the TDS board both run happily on 3.3 V and produce signals under 3.3 V. The turbidity board is the odd one out: it needs 5 V to run and its output can reach about 4.5 V. That is the wire that can fry your board, and it is why the turbidity sensor is the one with a voltage divider between it and the XIAO.

A common mistake is plugging a sensor into 5V "because it is more power". The TDS board and the temperature adapter are powered from 3.3 V precisely so their signal pins stay under the XIAO's limit. More volts in means more volts out.

What the divider does

A voltage divider is two resistors in series. The output is taken from across the smaller one, so the voltage is split in a fixed ratio. The divider module used in this build divides by 5, so a 4.5 V signal comes out at 0.9 V: safe for the pin.

The trade-off is detail. The XIAO reads analog accurately only up to about 2.5 V, and 0.9 V uses about a third of that range. For more resolution you can swap in two 10 kΩ resistors as a ÷2 divider, which keeps the output under 2.25 V. Either way, you multiply the reading by the ratio (5 or 2) in code.

The divider module's labels confuse almost everyone the first time:

Wiring the turbidity sensor

Keep the USB-C cable unplugged the whole time you wire. It goes in last.

Part 1: power the sensor and feed its signal into the divider

1. Slide the switch on the turbidity board to A (analog), not D.
2. Plug the included 3-wire cable into the board, and connect the probe.
3. Red jumper from the XIAO's 5V pin to the cable's V pin. This is the only 5V wire in the build, and it skips the breadboard power strip.
4. Cable's G wire into the ground (−) rail.
5. Cable's S wire into the divider's VCC screw terminal (the input). Tighten it and give it a gentle tug.

Part 2: ground the divider and send its safe signal to D2

1. Ground jumper from the − rail to the divider's GND terminal.
2. Ground jumper from the − rail to the divider's − pin.
3. Signal jumper from the divider's S pin to the XIAO's D2.
4. Leave the divider's + pin empty.

Only the clear lower part of the probe goes in the water. The top of the probe and every board stay dry.

Never plug the turbidity S pin straight into the XIAO.

Check everything before you power up

With the USB still unplugged, go through this list:

• The turbidity switch is on A.
• The 3V3 (+) rail has three wires: XIAO 3V3, temperature adapter VCC, TDS +. Nothing from 5V.
• Only one wire on 5V, going to the turbidity board's V.
• Turbidity S goes to the divider, not to the XIAO. D2 connects to the divider's S pin.
• Signals: D4 to the temperature adapter's DAT, D1 to the TDS board's A, D2 to the divider's S.
• No bare metal touching anything it should not. Every board is dry and above the water line.
• Each cable hangs in a small U-shaped drip loop below the electronics, so water runs off the bottom of the loop instead of into the boards.

Then plug in USB. Nothing should get warm and nothing should smell; if it does, unplug right away and recheck the 5V and GND wires.

Another common mistake: plugging the USB in "just to see the light" halfway through wiring. Every wire you add after that goes onto a live board, and a jumper that brushes 5V against a signal pin on its way in can take out the whole board. USB last, every time.

Two readings that tell you something is wrong

Once firmware is loaded, temperature should show a sensible number, TDS reads near zero in air and a steady number in the tank, and turbidity reads higher in clear water and drops when the water gets cloudy.

Two problems catch almost everyone:

• The temperature reads 85 °C. That is the DS18B20's power-on value, which means it never got a successful read. It is usually a loose DAT wire.
• Turbidity is flat no matter what the water does. The board's switch was left on D (digital) instead of A.

Get the one 5V wire right, put the divider in the turbidity signal path, and plug in USB last. The rest of the build is forgiving.

Go deeper: Smart Turtle Tank

Retention answers one question: how far back can you go? Most homelabs set it once, glance at keep-daily=7, and assume they have a week of history. That assumption is the trap.

The answer to "how far back" should come from your inventory of what you protect, not from how much disk you happen to have. And it starts with reading the keep-* options correctly.

The trap: buckets, not days

keep-daily=7 does not mean "keep seven days." It means "keep the last backup from each of the last seven days that have a backup."

That last part is the whole problem. Picture a job that fails quietly for a month and then runs once. That one good run satisfies keep-daily, keep-weekly and keep-monthly all at once, and pruning happily deletes the older backups. The rules keep the most recent backup for each calendar bucket; they never promise coverage of time.

So a retention policy that looks like three months of history on paper can collapse to a single backup, with no error anywhere, if the jobs stop running.

The second trap: retention doesn't fix a bad backup

Retention does not protect you from a backup that was bad when it was taken. If the guest was already corrupted when the backup ran, you now have seven pristine copies of corruption.

Retention is about reaching back past the moment something went wrong. That is why the weekly and monthly buckets matter more than the daily ones: a slow corruption can take weeks to notice, and by then the dailies have all rolled over.

How the rules combine

Each rule runs independently, and a backup survives if any rule claims it. That means you can tune the depth per type of guest instead of using one set of numbers for everything. The book's combination looks like this:

keep-last is the safety margin. It protects the newest backups even if they fall on the same day as a pruned one, and it covers the "you just took a backup before an upgrade" case.

Before you commit to any numbers, open the Prune Simulator in the Proxmox Backup Server docs (search for "Prune Simulator") and check what actually survives on a calendar. Proxmox's own retention example in the vzdump docs walks through the same thing and is worth reading once.

The fix: set it in one place

Retention belongs on the storage, not on each job. For a vzdump storage such as an NFS share, set it on the storage so every job that writes there inherits it:

pvesm set nas-backup \
  --prune-backups keep-last=2,keep-daily=7,keep-weekly=4,keep-monthly=3

For Proxmox Backup Server, retention lives in the datastore's prune job, and you can give different namespaces or groups different rules. Set the same keep-* numbers there that you chose for each guest type.

On the backup jobs themselves, leave Retention on "use storage defaults". Setting retention on a job as well gives you two sets of rules fighting each other.

On PBS, remember that pruning only unlinks the index. Garbage collection is what actually frees chunks, and only chunks older than a grace period (24 hours and 5 minutes by default). Schedule GC daily and expect free space to lag pruning by a day.

Changing the numbers later

Changing retention is safe in one direction only. Raising the numbers keeps more. Lowering them deletes on the next prune, with no undo.

If you are short on space, run the change through the simulator first, and if something has to give, shorten the vzdump retention, not the PBS one.

Protected backups for risky changes

Before any change you might regret, such as a major Home Assistant upgrade, a Proxmox major version, or migrating a database, take a manual backup and mark it protected. A protected backup survives every prune until you remove the flag.

In the Proxmox GUI, select the backup and tick Protected. On the command line:

V=pbs01:backup/vm/101/2026-10-04T01:30:00Z
pvesh set /nodes/pve1/storage/pbs01/content/$V --protected 1

Make a habit of clearing them after a month. Protected backups do not count toward keep-*, so they pile up.

How much space to plan for

Real numbers depend on your data, but the book gives a sizing rule of thumb for a new PBS disk: the first backup of a guest is roughly its used disk space after compression, and each further day adds about the daily change. For the book's mix of guests, a year of PBS history fits in about twice the live data.

For vzdump full copies, multiply the guest's used size by the number of copies you keep, then add a third for growth.

Checklist: retention

• Keep-* numbers chosen per guest type from your inventory, not from free space
• Checked in the prune simulator that a month of failed jobs cannot wipe your history
• Retention set on the storage or the PBS prune job, with jobs on "use storage defaults"
• PBS garbage collection scheduled daily
• A protected backup taken before every risky change, and cleared a month later
• Backup storage sized with room for a year of growth

Retention only keeps history if backups keep landing. A month of silent failures is exactly what turns keep-daily=7 into a single copy, so pair these numbers with an alert for jobs that stop running.

Go deeper: Never Lose Your Data

Every homelab accumulates guests. The container you built to try something, the VM from a tutorial, the old version of a service you migrated away from. Eventually most of the guest list is grey stopped icons, and the nightly backup job is dutifully copying all of them.

Cleaning house is easy to put off because deleting things is scary. The way to make it not scary is a routine where every single guest you delete is recoverable: back it up, verify the backup, then destroy with purge.

The trap: stopped is not the same as unused

A template is always stopped. A container that was turned into the base of linked clones is always stopped. Delete the base and the clones keep running until the next reboot, and then they do not.

So before you delete anything, find out what is actually unused.

Step 0: check for linked clones

For every stopped guest, check whether any config references its disks as a base:

for id in $(pct list | awk 'NR>1 && $2=="stopped"{print $1}') \
          $(qm list | awk 'NR>1 && $3=="stopped"{print $1}'); do
  if grep -lq "base-${id}-" /etc/pve/nodes/*/*/*.conf 2>/dev/null; then
    echo "KEEP $id: base for linked clones"
  else
    echo "candidate $id"
  fi
done

Tag anything marked KEEP as keep in the GUI and it is out of the discussion. Then walk the candidates with a human eye: the name, the notes, the last-modified date of its config. If you are not sure what a guest is, start it, look, stop it. Ten minutes per mystery guest is cheaper than one wrong destroy.

Step 1: back it up, in stop mode

A stopped guest does not need snapshot mode, and stop mode gives the most consistent archive. Write it to your backup storage with vzdump so the result is one portable file, and give it a note that will mean something in a year:

vzdump 212 --storage nas-backup --mode stop --compress zstd --bwlimit 60000 \
  --notes-template 'DELETED {{guestname}} ({{vmid}}) cleanup 2026-10'

Watch the backup storage's free space as you go. Work in order of "would be saddest to lose", and if the share gets tight, prune old nightly backups to make room before carrying on. The bandwidth limit keeps your busy guests from lagging while the dumps run; it costs a few minutes per guest.

Step 2: verify the archive

A backup you have not at least integrity-checked is a rumour. For a container archive:

zstd -t /mnt/pve/nas-backup/dump/vzdump-lxc-212-2026_10_09-21_14_03.tar.zst

VM archives are .vma.zst files and the same zstd -t works. This proves the file is whole and decompresses. It does not prove the guest boots. For anything you would truly mourn, go further: restore it to a new ID and start it with the network unplugged.

Then mark the archive protected, so the nightly prune cannot eat it:

F=vzdump-lxc-212-2026_10_09-21_14_03.tar.zst
pvesh set /nodes/pve1/storage/nas-backup/content/nas-backup:backup/$F \
  --protected 1

Step 3: destroy, with purge

pct destroy 212 --purge
# or
qm destroy 212 --purge

--purge removes the guest from every backup job, the replication config and HA. Without it, the nightly backup job keeps a reference to a guest that no longer exists and fails with an error about that ID every night until you edit the job by hand.

The loop

For more than a handful of guests, put the IDs in a file (one per line, after the human pass) and let a script do the three steps:

#!/bin/bash
set -u
STORE=nas-backup
DUMP=/mnt/pve/$STORE/dump
NOTE="DELETED {{guestname}} ({{vmid}}) cleanup $(date +%Y-%m)"
while read -r id; do
  if pct config "$id" >/dev/null 2>&1; then kind=lxc; cmd=pct
  else kind=qemu; cmd=qm; fi
  echo "== $id ($kind)"
  vzdump "$id" --storage $STORE --mode stop --compress zstd \
    --bwlimit 60000 --notes-template "$NOTE" \
    || { echo "backup FAILED $id"; continue; }
  f=$(ls -t $DUMP/vzdump-$kind-$id-*.zst | head -1)
  zstd -t "$f" || { echo "verify FAILED $id"; continue; }
  vol="$STORE:backup/$(basename "$f")"
  pvesh set /nodes/$(hostname)/storage/$STORE/content/$vol --protected 1
  $cmd destroy "$id" --purge || echo "destroy FAILED $id (retry later)"
done < /root/cleanup-ids.txt

Every continue means a failure leaves the guest in place. Nothing is ever destroyed without a verified archive ahead of it.

Two gotchas

Cluster quorum. On a two-node cluster, if one node drops off, destroys on the cluster fail with a quorum error while it is out. Re-run the failed IDs once the cluster is quorate again. The proper fix is a QDevice, so the cluster has a third vote.

Leftover locks. Proxmox will not back up or destroy a guest while a lock from an earlier interrupted job is set. pct unlock 212 or qm unlock 212 clears it, once you have checked nothing is actually running against the guest.

Afterwards: the orphans

With the guests gone, there is a second layer of junk:

• Orphan disks: entries in pvesm list local-zfs that no config references. Compare against grep -h 'local-zfs:' /etc/pve/nodes/*/*/*.conf. Back each one up as a raw image before removing it, same rule.
• Old ISOs and container templates in local. They download again in minutes.
• Year-old snapshots on running guests (qm listsnapshot <id>, pct listsnapshot <id>). A snapshot that old is a backup you forgot, on the same disk as the data, slowing every write.

Checklist

• Every stopped guest checked for linked clones (base-<id>- in any config); templates tagged keep
• A stop-mode vzdump of each candidate with a "DELETED" note, bandwidth-limited
• zstd -t on every archive, and the archive marked protected
• destroy --purge, never plain destroy
• Failed steps leave the guest in place
• Orphan disks, old ISOs and year-old snapshots cleaned in a second pass

Go deeper: Never Lose Your Data