Portainer Alternatives?

I've been using Portainer for a while now.  I'm not using it as efficiently as I should, but that's a discussion for another day.

I wanted to explore other alternatives to Portainer and landed on Arcane.

I had serious issues getting Arcane set up as a Docker instance, but there's an alternative method - I ran the following command:

curl -fsSL https://getarcane.app/install.sh | sudo bash

No, this does not leverage Docker, but I was frustrated in getting Arcane to run within a container.  I'll double back to get that working later.

What I like is that Arcane detects all the pre-existing containers.  I didn't have to set anything up.

One thing I've noticed is that, when I restarted a Wordpress container, Arcane froze and wouldn't let me back in.  As I was going to restart the Arcane service, it came back up.  Arcane is running on a Pi 500, but it is pretty robust as far as Pis go.

Another thing - I'm unable to see the containers' compose files from the Arcane console.  Maybe I'm not looking in the correct areas of the console.  This is something to research.

The very cool thing is that Arcane has security findings if you enable container security scanning!  I think it's using the Trivy scanner.  As well, if you click on a discovered CVE, it points directly to the NIST CVE entry.

I'll also be testing Dockge, Dokploy, Coolify, and Dockhand, as well.  I'll share my thoughts as I test.

Uptime Kuma Has No Built-In Backup Strategy!

I've been using Uptime Kuma to monitor my LAN and external systems.

I'd noticed that Uptime Kuma had an update.  I was hesistant to apply the update because I might lose my configuration data, but tried it anyways.  Yeah, I lost everything.

I'd looked into the settings to see if there was a backup strategy but didn't see anything.

I used AI to determine if there was an alternative backup solution.  The AI stated that the Uptime Kuma (UK) developer had issues with a configuration backup solution and had reverted what existed.

I asked it to give me a script to use as a backup solution.  Based on the Docker compose file that I'm using (which I provided to the AI), it presented me this:

#!/bin/bash

# --- CONFIGURATION ---

CONTAINER_NAME="uptime-kuma"

#SOURCE_DIR="/app/data" # Or your specific host path found in Step 1

SOURCE_DIR="/data/compose/28/uptime-kuma-data"

BACKUP_DIR="/opt/stacks/backups/uptime-kuma"

TIMESTAMP=$(date +"%Y%m%d_%H%M%S")

BACKUP_NAME="kuma_backup_$TIMESTAMP.tar.gz"

RETENTION_DAYS=30

# ---------------------

# Ensure backup directory exists

mkdir -p "$BACKUP_DIR"

echo "Starting Uptime Kuma backup..."

# 1. Stop the container to freeze the SQLite DB safely

docker stop "$CONTAINER_NAME"

# 2. Compress the data directory

tar -czf "$BACKUP_DIR/$BACKUP_NAME" -C "$(dirname "$SOURCE_DIR")" "$(basename "$SOURCE_DIR")"

# 3. Restart the container immediately

docker start "$CONTAINER_NAME"

# 4. Clean up backups older than X days

find "$BACKUP_DIR" -type f -name "kuma_backup_*.tar.gz" -mtime +$RETENTION_DAYS -exec rm {} \;

echo "Backup completed successfully: $BACKUP_DIR/$BACKUP_NAME"

I tested it several times.  There was an issue with the source directory values, which I sorted.  Once I sorted that, the script worked.

I then created a cron job for the script:

# Backup of Uptime-Kuma

0 2 * * 1 /usr/local/bin/backup-kuma.sh > /dev/null 2>&1

One cool option is that I can set the retention days for the backup data.  Anything older than 30 days, for example, gets removed.  That value can also be changed (it was initially set to backup on a daily basis).

I also asked the AI to present restoration steps, which it did.  I documented that for later use.  I will ask it, later, to create a script of the restoration steps.

That is my backup solution.

The backup solution is mainly so that I do not have to recreate the UK monitors if I lose them during an upgrade of Uptime Kuma.