Homey Self-Hosted Server on Proxmox | Megathread

[Olex]

Many thanks for your help!

From the console inside of the Proxmox:

ls -lsa /root/.homey-shs/
drwxr-xr-x 8 root root 4096 Jan 25 09:57 .
4 drwx------ 5 root root 4096 Jan 25 12:55 ..
4 drwxr-xr-x 3 root root 4096 Jan 25 10:33 apps
4 drwxr-xr-x 2 root root 4096 Jan 25 09:57 insights
4 drwxr-xr-x 2 root root 4096 Jan 25 12:58 matter
4 drwxr-xr-x 3 root root 4096 Jan 25 09:56 matter-certs
4 drwxr-xr-x 2 root root 4096 Jan 25 10:33 rrd
4 drwxr-xr-x 2 root root 4096 Jan 25 12:58 sqlite
root@homey-shs:~#

docker inspect -f ‘{{ json .Mounts }}’ homey-shs | jq
[
{
“Type”: “bind”,
“Source”: “/root/.homey-shs”,
“Destination”: “/homey/user”,
“Mode”: “”,
“RW”: true,
“Propagation”: “rprivate”
}
]

Using the command “grep -n PasswordAuthentication /etc/ssh/sshd_config” gives mixed result:

Runnig shell from “heim” it gives:
root@heim:~# grep -n PasswordAuthentication /etc/ssh/sshd_config
57:PasswordAuthentication yes
79:# PasswordAuthentication. Depending on your PAM configuration,
83:# PAM authentication, then enable this but set PasswordAuthentication

From 100 (homey-shs), it gives:
57:#PasswordAuthentication yes
81:# PasswordAuthentication. Depending on your PAM configuration,
85:# PAM authentication, then enable this but set PasswordAuthentication

I could live with performing backup/restore from within the Proxmox installation, but can’t see the way to achive that.

[Anoniemand]

heim is your proxmox node, so that’s why you see differences.

For SSH access to homey-shs you’ll need to make sure all of the actions are applied on homey-shs and not (by mistake) on the pve node: heim.

Enable SSH access via Password

on homey-shs on line 57 PasswordAuthentication yes exists, but as a comment, you’ll need to remove the # at the start of that line (using nano /etc/ssh/sshd_config), see also my previous instructions.

Than exit / save the file and restart sshd.

ssh root@192.168.1.100 should work than.

Backup / restore

For backup/restore in Proxmox there are other ways. Preferably using proxmox backup server (because of dedup and incremental backups), but you can also use the built in function from PVE. That’s good enough to start with.

[Olex]

Thanks so much for your help! I’ll absorb this and give it another try. My wife keeps saying that when you’re in your mid-60s, maybe it’s time to find a new hobby…

[Anoniemand]

No problem. The easiest way (for backup) would be the use of backup restore within PVE.

For the way you started, the backup method from the install guide, after SSH is enabled, you still need to create something that copies the files from that folder to another target (preferably not the container itself). So there’s more to it after SSH is fixed

Happy Sunday

[ridderdk]

Can someone point me in the right direction?
Everything in my homey selfhosted server is working as supposed (to my knowledge), except the scripting engine seems to be “gone”?
Please see bitmaps attached, can anything be done?
Note, it’s not a browser problem, the same is showing on 4 different pc’s and 3 different browsers.

[Peter_Kawa]

It seems to be ‘half installed’, something like that;
Maybe reinstalling Homeyscript helps?

HomeyScript | Homey

[ridderdk]

thank you Peter, that was it

[John_Hall]

Did you find the Website username and password?

[Anoniemand]

What website are you referring to?

[John_Hall]

Homey Self-Hosted Server (113) is ready.
Hostname. : homey-shs
IP : 10.0.0.142
SSH Username : root
SSH Password : homey
HTTP Address : http://10.0.0.142:4859

I’d like to change the password from whatever the default is. It is not what the install script says it is.

[Anoniemand]

In that screen there are two types access:

SSH: remote access via command line, with specified username and password.
HTTP: remote access via Graphical User Interface. The given username and password do not apply to this website.

During setup via smartphone, you will make sure your Homey account will get access to your Homey Self Hosted instance. To access Homey via the local address (http://10.0.0.142…) instead of the public address (my.homey.app) you’ll need to enable the local account as explained in here.

[John_Hall]

Sorry for the delay in responding I was in Homey forum jail for posting as a new user. The install script for Proxmox doesn’t make it very clear this is what is required it just gives the info to be able to log in but as you’ve said that is not the case. Maybe a dev will read this and add an additional line of text to indicate this.

[Anoniemand]

It’s explained in the main “how to install” guide (here), at least that you’ll need a smartphone to setup to install.

For the Proxmox installer, i havent checked the one supplied by Athom recently, but i’ve created an interactive installer which has more options than the one supplied by Athom at the start of this year.

[John_Hall]

I did follow the guide and it makes no mention of the local webserver. I like a lot of Proxmox user see the local webserver with a default username and password at the end of the install and immediately want to change this as it is a security risk. A quick change to the install script to state something like this

Homey Self-Hosted Server (113) is ready.
Hostname. : homey-shs
IP : 10.0.0.142
SSH Username : root (disabled by default)
SSH Password : homey
HTTP Address : http://10.0.0.142:4859

Might belay some of the fears.

[MedievalRoadie]

Hi!

I’ve recently written a little Homey app in Python and released it onto the forums for some testing. A user has submitted an error & stack trace (and kindly followed up on the forums), showing an error mounting /dev/random. I’m not doing anything with /dev/random, but managed to reproduce the issue by installing on a freshly-created Proxmox LXC (using the provided installation script).

I don’t think I’m doing anything strange, but to try to confirm I checked with a fresh/empty Python project created using homey app create and I get the same thing, a crash while being unable to mount /dev/random. This only seems to happen with homey app install though - Just running with homey app run seems to be fine.

Would someone be able to test/confirm please?

To reproduce:

1. Either have a Proxmox SHS install created with the script at https://support.homey.app/hc/en-us/articles/23975241078940-How-to-install-Homey-Self-Hosted-Server-on-Proxmox. Or stand up a new server

2. Create a new Python Homey app using homey app create

3. Install the unmodified app with homey app install. App immediately crashes

4. run the unmodified app with homey app run. All seems to run fine

Thanks!

Edit: Additionally, backing-up the created Proxmox LXC and then restoring it as privileged seems to allow installed Python apps to run properly.

[Peter_Kawa]

@MedievalRoadie

This only seems to happen with homey app install though - Just running with homey app run seems to be fine.

To actually run an app on Homey Pro 202x / mini (instead of running it on a local docker image), you’re supposed to call homey app run --remote

This most probably is why you see these different results.

All posts mentioning the homey app run command:
https://community.homey.app/search?q=homey%20app%20run%20–remote

The howto:

[HOW TO] CLI install method

Homey Pro only!!! It does not work this way with Homey (cloud), it only supports CLI run which is there only for development purposes. Installing Node.js Check Node.js version on Homey: Homey App: Settings - General - About - Node.js version Download Node.js (use Homey’s version or higher) from https://nodejs.org/ and install it on your computer. Download the app you want to install from GitHub Go to the repository on GitHub (the correct link for the app you want to install is at the bottom…

[MedievalRoadie]

Hi, and thanks for the additional info - I wasn’t aware of --remote, and testing this morning reveals that it does act the same as install.

The issue remains though - installing or running a Python app (with --remote) on the default Proxmox SHS install causes the app to crash with complaints about being unable to mount /dev/random. I don’t think /dev/random can be mounted as an unprivileged LXC container, which is what the install script defaults to.

[Peter_Kawa]

No problem.
I guessume it’s best to contact Athom (homey.app/support), if you think it’s a bug.

[Bekkenes]

I found the default “update on reboot” behavior for Homey Self-Hosted on Proxmox to be inefficient and unnecessary. Docker containers don’t need a full LXC reboot to update.

I’ve implemented a simple, automated solution that checks for updates daily at 04:00 and only restarts the container if a new image version is actually detected. This removes the need for manual reboots and avoids downtime when no update is available.

Step 1: Modify the update script Edit /usr/local/bin/homey-shs.sh and replace its contents with this logic:

Bash

#!/usr/bin/env bash
set -Eeuo pipefail
IMAGE="ghcr.io/athombv/homey-shs"
CONTAINER="homey-shs"
DATA_DIR="/root/.homey-shs"

# Check for update
PULL_OUTPUT=$(LANG=C docker pull "$IMAGE")

if echo "$PULL_OUTPUT" | grep -q "Image is up to date"; then
    echo "[homey-shs] Image is already up to date. No action taken."
    exit 0
fi

echo "[homey-shs] New image detected. Updating..."
docker stop "$CONTAINER" >/dev/null 2>&1 || true
docker rm "$CONTAINER" >/dev/null 2>&1 || true
docker run \
  --name="$CONTAINER" \
  --network host \
  --privileged \
  --detach \
  --restart unless-stopped \
  --volume "$DATA_DIR":/homey/user/ \
  "$IMAGE"

Step 2: Create a systemd timer for automation Create /etc/systemd/system/homey-shs-update.service:

Ini, TOML

[Unit]
Description=Update Homey Self-Hosted Container

[Service]
Type=oneshot
ExecStart=/usr/local/bin/homey-shs.sh

Create /etc/systemd/system/homey-shs-update.timer:

Ini, TOML

[Unit]
Description=Run Homey update daily

[Timer]
OnCalendar=*-*-* 04:00:00
Persistent=true

[Install]
WantedBy=timers.target

Step 3: Enable the timer Run this in your LXC shell:

Bash

systemctl daemon-reload
systemctl enable --now homey-shs-update.timer

Now your Homey server will stay up-to-date automatically at 04:00 without requiring any LXC reboots.

[Jari_Peuhkurinen]

I just recently noticed that Homey Self-Hosted Server updates automatically on every reboot and the startup script automatically pulls the latest Docker image every time the container or host restarts.

While this keeps the system updated, it completely breaks the “local-first” principle. After a brief power outage and host reboot, my system pulled an unstable version, breaking my smart home logic when I actively wanted to stay on the stable release.

Relying on the latest tag is a risk for production-critical environments. Here is a quick fix to remove the forced auto-update, take back local control, and pin your Homey SHS to a specific, stable version.

The Root Cause

The homey-shs.service systemd service delegates container startup to a shell script located at /usr/local/bin/homey-shs.sh. This script contains a hardcoded docker pull command and lacks a specific version tag for the image.

The Fix (Version Pinning)

Access your Proxmox LXC console and open the script in a text editor:

nano /usr/local/bin/homey-shs.sh

Delete the existing code (especially the docker pull block) and replace the entire file with this clean, pinned configuration.

Note: You can modify the IMAGE variable to match the exact version you want to lock into.

#!/usr/bin/env bash
set -Eeuo pipefail

IMAGE="ghcr.io/athombv/homey-shs:13.1.5"
CONTAINER="homey-shs"
DATA_DIR="/root/.homey-shs"

# Create data directory if it does not exist
mkdir -p "$DATA_DIR"

# Stop and remove the old container in the background (if it exists)
docker rm -f "$CONTAINER" >/dev/null 2>&1 || true

# Start the new container
docker run \
  --name="$CONTAINER" \
  --network=host \
  --privileged \
  --detach \
  --restart=unless-stopped \
  --volume "$DATA_DIR":/homey/user/ \
  "$IMAGE"

Save the file, exit your editor, and execute the script manually to forcefully remove the old, unstable container and spin up the newly pinned version:

bash /usr/local/bin/homey-shs.sh

This is 100% safe because the original script wisely uses a bind-mount --volume "$DATA_DIR":/homey/user/ , so all your devices, logic, and databases are stored safely on the host system.

The Docker container itself is stateless. Destroying the old container and spinning up the pinned version takes only a few seconds, and no data is lost.

When you are ready to update to a newer stable version in the future, simply edit the IMAGE tag in the script to the new version and run the bash command again.