Update rusty-kaspad to version v1.1.0-1

[elldeeone]

Summary

This updates rusty-kaspad to app version v1.1.0-1.

The bundled Rusty Kaspa node remains on v1.1.0. The -1 suffix is an Umbrel app/package revision for the new frontend/runtime packaging.

Changes

• update the frontend image to elldee/kaspa-frontend:v0.4.0@sha256:a419270a224df638d10cef7bc60edd3a930a4a08dda4c14aee1eaaf892a59ef4
• remove the old Python API/log-buffer architecture
• keep the app on Rusty Kaspa v1.1.0
• fix the kaspad data mount to use /app/data, which is where the official image stores .rusty-kaspa
• add a pre-start migration hook to move legacy anonymous-volume node data into Umbrel-managed app data for existing installs
• bump manifestVersion to 1.1 for hooks support
• update packaged-by URL to https://dunshea.au

Why this is needed

The previous package mounted ${APP_DATA_DIR}/data/app to /data, but the official kaspanet/rusty-kaspad image stores the actual database under /app/data/.rusty-kaspa.

That meant existing installs could keep their real node database in an anonymous Docker volume instead of Umbrel-managed app data.

This PR corrects the mount and adds a one-time move-based migration for existing installs.

Validation

Tested on a local x86_64 Umbrel VM (umbrel.local):

• verified the live app runs correctly with the new frontend package
• verified kaspad runs from ${APP_DATA_DIR}/data/app -> /app/data
• verified the old anonymous data volume is no longer used after migration
• verified the node continued syncing from migrated data instead of starting fresh
• verified the dashboard reached healthy connected/synced state
• ran a synthetic end-to-end legacy migration test for the new pre-start hook:
  • legacy anonymous /app/data volume detected
  • .rusty-kaspa moved into Umbrel app data
  • second run correctly no-ops

Images

• elldee/kaspa-frontend:v0.4.0@sha256:a419270a224df638d10cef7bc60edd3a930a4a08dda4c14aee1eaaf892a59ef4
• kaspanet/rusty-kaspad:v1.1.0@sha256:150ffa0c0dcc6497951f9199d1ba3e48c7d91ef958846b28c9fb5045459a2dca

[al-lac]

Hey @elldeeone,

thanks a lot for providing this update to rusty kaspad! 💯

I am unsure that some of these changes are really needed. Maybe you can elaborate on the comments I have added.

[al-lac]

@elldeeone, looking better now! Thanks for making the adaptions.

Data is also being stored in the correct place now:

root@umbrel-dev:/home/umbrel/umbrel/app-data/rusty-kaspad/data# du -sch ./*
1.1G	./app
36K	./logs
1.1G	total

But restarts still seem to be an issue (starts fresh):

root@umbrel-dev:/home/umbrel/umbrel/app-data/rusty-kaspad/data# du -sch ./*
388M	./app
36K	./logs
388M	total

We should probably add something like this to exclude the blockchain from backups:

backupIgnore:
  - data/app

Can you test this some more and let me know when it is ready?

[al-lac]

Hey @elldeeone, I managed to fully sync a node now. Tried a restart and it is taking forever, we probably should add something like this so it get force stopped / restarted after some minutes. But maybe you can look into it so it shuts down faster and clean per default.

Stop workaround:

stop_grace_period: 3m

[elldeeone]

Thanks @al-lac, I did another round of testing and pushed a follow up update.

To clarify the restart concern:

• During early on in the Kaspa nodes Initial Block Download, restarting can make the node appear to start fresh again (which is why you will see db size change). That is normal behaviour during IBD, not a remaining issue with the mount fix.
• After a full sync, restart resumes correctly.

On the shutdown side:

• I also looked into the long stop/restart time on a fully synced node. Part of that was the frontend not handling SIGTERM cleanly, so I fixed that in the frontend and updated the app to elldee/kaspa-frontend:v0.4.1.
• After that change, kaspad was still hitting SIGKILL after 1 minute on stop, so I added stop_grace_period: 3m for kaspad.
• With the current PR state, a stop on my synced Umbrel test node completed in about 17s and kaspad exited cleanly with exit code 0 instead of being force-killed.

I also introduced explicit container names in the compose, as I found the app proxy behaviour was a little inconsistent without them and this makes rusty-kaspad_frontend_1 resolve reliably.

This should now be ready for another look when you have a moment.

[al-lac]

Hey @elldeeone, thanks a lot for making the adaptions. Looking good from my point of view!

I removed the container names again, never had any issues with them until now. Please specify what issues you saw exactly so we can investigate this.

Other than that, we would be ready to go now.

[github-actions]

🎉   Linting finished with no errors or warnings   🎉

Thank you for your submission! This is an automated linter that checks for common issues in pull requests to the Umbrel App Store.

Please review the linting results below and make any necessary changes to your submission.

Linting Results

Severity	File	Description
ℹ️	rusty-kaspad/docker-compose.yml	External port mapping "16110:16110": Port mappings may be unnecessary for the app to function correctly. Docker's internal DNS resolves container names to IP addresses within the same network. External access to the web interface is handled by the app_proxy container. Port mappings are only needed if external access is required to a port not proxied by the app_proxy, or if an app needs to expose multiple ports for its functionality (e.g., DHCP, DNS, P2P, etc.).
ℹ️	rusty-kaspad/docker-compose.yml	External port mapping "16111:16111": Port mappings may be unnecessary for the app to function correctly. Docker's internal DNS resolves container names to IP addresses within the same network. External access to the web interface is handled by the app_proxy container. Port mappings are only needed if external access is required to a port not proxied by the app_proxy, or if an app needs to expose multiple ports for its functionality (e.g., DHCP, DNS, P2P, etc.).
ℹ️	rusty-kaspad/docker-compose.yml	External port mapping "17110:17110": Port mappings may be unnecessary for the app to function correctly. Docker's internal DNS resolves container names to IP addresses within the same network. External access to the web interface is handled by the app_proxy container. Port mappings are only needed if external access is required to a port not proxied by the app_proxy, or if an app needs to expose multiple ports for its functionality (e.g., DHCP, DNS, P2P, etc.).
ℹ️	rusty-kaspad/docker-compose.yml	External port mapping "18110:18110": Port mappings may be unnecessary for the app to function correctly. Docker's internal DNS resolves container names to IP addresses within the same network. External access to the web interface is handled by the app_proxy container. Port mappings are only needed if external access is required to a port not proxied by the app_proxy, or if an app needs to expose multiple ports for its functionality (e.g., DHCP, DNS, P2P, etc.).
ℹ️	rusty-kaspad/docker-compose.yml	Potentially using unsafe user in service "frontend": The default container user "root" can lead to security vulnerabilities. If you are using the root user, please try to specify a different user (e.g. "1000:1000") in the compose file or try to set the UID/PUID and GID/PGID environment variables to 1000.
ℹ️	rusty-kaspad/docker-compose.yml	Potentially using unsafe user in service "kaspad": The default container user "root" can lead to security vulnerabilities. If you are using the root user, please try to specify a different user (e.g. "1000:1000") in the compose file or try to set the UID/PUID and GID/PGID environment variables to 1000.

Legend

Symbol	Description
❌	Error: This must be resolved before this PR can be merged.
⚠️	Warning: This is highly encouraged to be resolved, but is not strictly mandatory.
ℹ️	Info: This is just for your information.

[elldeeone]

@al-lac I rechecked this from scratch and it looks like the issue i saw earlier was a byproduct of how i was debugging it, so it's a non-issue.

I had manually replaced the generated app-data compose during testing, which is not the same path as a normal Umbrel install. When installed normally, I could not reproduce the hostname issue again.

From my side this should be good to go now. Thanks!

[al-lac]

Awesome job @elldeeone. Great to work with you on this.

Tested it one more time and also good from my side, going live! 🚀