You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
arm64 update: the blocker is resolved on the Rackula side.
The release tarball now bundles the native @node-rs/argon2 binary for both x86-64 and arm64. The build installs with bun install --cpu='*' --os=linux and fails if either architecture's binary is missing. argon2 is the only native dependency.
Verified on native arm64 Linux (not emulation): a tarball-parity build loaded argon2 and round-tripped an Argon2id hash under linux/arm64, both locally and in a CI job on a ubuntu-24.04-arm runner.
This lands with the Rackula v26.6.0 release. Since the install script pulls the latest release, arm64 will work as soon as v26.6.0 is published (the first release carrying the arch-complete tarball). I will flip var_arm64/has_arm and update this request to arm64-supported once that release is out.
arm64 is now supported. The Rackula v26.6.1 release tarball bundles the native @node-rs/argon2 binary for both x86-64 and arm64 (verified loading under Bun on a native arm64 runner), and the script advertises arm64 (var_arm64=yes, has_arm: true).
The script follows community-scripts conventions: fetch_and_deploy_gh_release for install and update, no custom download or checksum logic, no curl dependency, and data preserved across updates. Two intentional deviations (a dedicated rackula user for token security, and an nginx reverse proxy) are explained in the PR description.
Looks like there is a >6 month project age requirement. Rackula's first repo commit was on Dec 26th 2025, though that was a migrated repo from the original project name Rackarr with it's first commit on Nov 27, 2025. Therefore, I'd consider Rackula is actually > 6 months old, though the repo age is only 5 months.
hey @michelroegl-brunner I think this was closed in error. #15052 is the arm64 porting batch (setting arm64 status on existing scripts) and doesn't add Rackula. Rackula's submission is PR #1897, which is still open. Could we reopen this issue? cc @vhsdream
Btw, these "verifying" code blocks should be removed. Why are you verifying files that you're literaly creating some lines before. You should always assume that they are correct, you're the one editing them. Having a check that will fail if some nginx config or something is wrong makes no sense. Users wont spend time correcting nginx configs.
Removed both Verifying Services health-check loops and the Bun -x self-check.
nginx -t: collapsed the hand-rolled gate to the one-line $STD nginx -t that every other nginx script uses (aliasvault, simplelogin, discourse, …). It still aborts on a genuinely broken config via silent(), but with no bespoke message/friction — happy to drop the test entirely if you'd prefer zero nginx checks.
While testing the update path I also hit a separate 404: the update fetch was passing ${var_version} (the Debian version, 13) as the release tag, so it failed after stopping services + backing up data. Switched it back to "latest" to match the install path (kept as its own commit in #1928).
Verified end-to-end on PVE 9.1.9 / Debian 13 LXC: fresh install and forced update (26.6.2 → 26.6.3) both come up healthy (/api/health 200, frontend 200), data preserved across the update.
@CerberusStyle's daemon-reload warning is real too — the update no longer runs systemctl daemon-reload after copying unit files. Flagged it in #1928; can fold the reload in there or do a follow-up, whichever you prefer.
@CerberusStyle that warning means the update rewrites the systemd unit files (rackula-api.service + the nginx.service.d drop-in) but never runs 'systemctl daemon-reload' before starting services, so systemd starts from the stale definitions. When a release changes those units it drops nginx (226/NAMESPACE) and rackula-api (31/SYS) while the update still reports success and advances the version marker.
Fix is a one-line daemon-reload before service start, in both the install and update paths. Reproduced and verified on amd64 (PVE 9.2 LXC) and arm64 (Deb13): #1944
Activity
ggfevans commentedon Jun 5, 2026
this is currently blocked until I get the LXC build pipeline working as expected, this will be part of a forthcoming 26.6.0 release of Rackula
ggfevans commentedon Jun 5, 2026
arm64 update: the blocker is resolved on the Rackula side.
The release tarball now bundles the native @node-rs/argon2 binary for both x86-64 and arm64. The build installs with
bun install --cpu='*' --os=linuxand fails if either architecture's binary is missing. argon2 is the only native dependency.Verified on native arm64 Linux (not emulation): a tarball-parity build loaded argon2 and round-tripped an Argon2id hash under linux/arm64, both locally and in a CI job on a
ubuntu-24.04-armrunner.This lands with the Rackula v26.6.0 release. Since the install script pulls the latest release, arm64 will work as soon as v26.6.0 is published (the first release carrying the arch-complete tarball). I will flip
var_arm64/has_armand update this request to arm64-supported once that release is out.ggfevans commentedon Jun 5, 2026
PR opened: #1893.
arm64 is now supported. The Rackula v26.6.1 release tarball bundles the native @node-rs/argon2 binary for both x86-64 and arm64 (verified loading under Bun on a native arm64 runner), and the script advertises arm64 (var_arm64=yes, has_arm: true).
The script follows community-scripts conventions: fetch_and_deploy_gh_release for install and update, no custom download or checksum logic, no curl dependency, and data preserved across updates. Two intentional deviations (a dedicated rackula user for token security, and an nginx reverse proxy) are explained in the PR description.
ggfevans commentedon Jun 6, 2026
Looks like there is a >6 month project age requirement. Rackula's first repo commit was on Dec 26th 2025, though that was a migrated repo from the original project name Rackarr with it's first commit on Nov 27, 2025. Therefore, I'd consider Rackula is actually > 6 months old, though the repo age is only 5 months.
michelroegl-brunner commentedon Jun 11, 2026
Merged with #15052 in ProxmoxVE
ggfevans commentedon Jun 12, 2026
hey @michelroegl-brunner I think this was closed in error. #15052 is the arm64 porting batch (setting arm64 status on existing scripts) and doesn't add Rackula. Rackula's submission is PR #1897, which is still open. Could we reopen this issue? cc @vhsdream
MickLesk commentedon Jun 12, 2026
michels bot is drunk
ggfevans commentedon Jun 12, 2026
PR #1897 merged! <3
MickLesk commentedon Jun 12, 2026
Dont Close. We need the Task for our actions
4 remaining items
tremor021 commentedon Jun 15, 2026
Script updated to use our backup functions.
Btw, these "verifying" code blocks should be removed. Why are you verifying files that you're literaly creating some lines before. You should always assume that they are correct, you're the one editing them. Having a check that will fail if some nginx config or something is wrong makes no sense. Users wont spend time correcting nginx configs.
This needs to work out-of-the-box
ggfevans commentedon Jun 16, 2026
Thanks @tremor021 — addressed in #1928:
Verifying Serviceshealth-check loops and the Bun-xself-check.nginx -t: collapsed the hand-rolled gate to the one-line$STD nginx -tthat every other nginx script uses (aliasvault, simplelogin, discourse, …). It still aborts on a genuinely broken config viasilent(), but with no bespoke message/friction — happy to drop the test entirely if you'd prefer zero nginx checks.While testing the update path I also hit a separate 404: the update fetch was passing
${var_version}(the Debian version,13) as the release tag, so it failed after stopping services + backing up data. Switched it back to"latest"to match the install path (kept as its own commit in #1928).Verified end-to-end on PVE 9.1.9 / Debian 13 LXC: fresh install and forced update (26.6.2 → 26.6.3) both come up healthy (
/api/health200, frontend 200), data preserved across the update.@CerberusStyle's
daemon-reloadwarning is real too — the update no longer runssystemctl daemon-reloadafter copying unit files. Flagged it in #1928; can fold the reload in there or do a follow-up, whichever you prefer.michelroegl-brunner commentedon Jun 21, 2026
Merged with #15255 in ProxmoxVE
CerberusStyle commentedon Jun 21, 2026
@ggfevans any updates on this? Just did i quick test and still seeing same error i did before on update.
ggfevans commentedon Jun 22, 2026
@CerberusStyle that warning means the update rewrites the systemd unit files (rackula-api.service + the nginx.service.d drop-in) but never runs 'systemctl daemon-reload' before starting services, so systemd starts from the stale definitions. When a release changes those units it drops nginx (226/NAMESPACE) and rackula-api (31/SYS) while the update still reports success and advances the version marker.
Fix is a one-line daemon-reload before service start, in both the install and update paths. Reproduced and verified on amd64 (PVE 9.2 LXC) and arm64 (Deb13): #1944
tremor021 commentedon Jun 22, 2026
merged #1944
github-actions commentedon Jun 29, 2026
A PR has been created for rackula: community-scripts/ProxmoxVE#15465
github-actions commentedon Jul 5, 2026
Files deleted with PR #1979