Cloudron Forum

@robi Totally agree...

@LoudLemur Thanks for this interesting question. It could be ok to draft docs by hand, then refine and polish with AI...

AI is too much verbose, as @girish noted....

@nottheend @girish

@nottheend said:

In the network UI, there is a setting called "VPN protection". First enable the feature and select how to route the client traffic.

This is a great feature. I hope it can be documented more thoroughly, to better understand how to benefit from it in all use cases and scenarios.

Thanks for your prompt response @girish.

@james Thanks a lot !

Hi all

I encountered an issue while upgrading Cloudron from 9.2.0 to 10.0.2 on Ubuntu 24.04.

I investigated with ChatGPT, and below you can find report that I asked to write.

I hope this can help to fix the installation script.

Thanks

---

After the upgrade, the dashboard was unreachable. Running:

sudo cloudron-support --troubleshoot

reported:

Database migrations are pending.
Last migration in DB: 20260330000000-backupSites-remove-disk-provider.js
Last migration file: 20260820150000-users-add-loginLocationsJson.js

The Box service was running, but box.log contained:

Unknown column 'apps.requiresVpn' in 'field list'

The missing column should have been created by:

20260624120000-apps-add-requiresVpn.js

Disk space and inodes were fine, and MySQL, Docker and nginx were running normally.

Looking at the update task and previous boot journal, I found this sequence:

installer: stop box service for update
installer: switching the box code
installer: calling box setup script
start: Configuring nginx
Warning! D-Bus connection terminated.
Failed to wait for response: Connection reset by peer

At approximately the same time, apt-daily-upgrade.service and unattended-upgrade started. This caused a systemd re-execution, after which:

cloudron-updater.service: Main process exited, status=1/FAILURE

It appears that the new 10.0.2 code was installed, but the setup script stopped before applying the database migrations. This left the Cloudron code and database schema out of sync.

Recovery

I temporarily stopped and runtime-masked the automatic APT services to prevent another concurrent run:

sudo systemctl stop apt-daily.timer apt-daily-upgrade.timer
sudo systemctl stop apt-daily.service apt-daily-upgrade.service packagekit.service

sudo systemctl mask --runtime \
  apt-daily.service \
  apt-daily-upgrade.service \
  packagekit.service

After confirming that no active APT or DPKG operation was running, I stopped Box and ran the troubleshooting command again:

sudo systemctl stop box
sudo cloudron-support --troubleshoot

Because Box was down, the support tool automatically reran the Cloudron startup/migration script. All pending migrations were then processed successfully, including:

Processed migration 20260624120000-apps-add-requiresVpn
...
Processed migration 20260820150000-users-add-loginLocationsJson
Done

It also restarted Box automatically.

A subsequent check showed:

[OK] dashboard is reachable via loopback
[OK] No pending database migrations
[OK] box v10.0.2 is running
[OK] Dashboard is reachable via IPv4

PASS: 29
WARN: 0
FAIL: 0

The dashboard also returned HTTP 200.

Finally, I restored the APT services:

sudo systemctl unmask --runtime \
  apt-daily.service \
  apt-daily-upgrade.service \
  packagekit.service

sudo systemctl start apt-daily.timer apt-daily-upgrade.timer

Everything is now working correctly.

Could this have been caused by a race between the Cloudron setup script and apt-daily-upgrade? Would it make sense for the updater to temporarily inhibit automatic APT jobs or automatically resume the migration phase if the detached updater service is interrupted?

@humpty Yes, I rolled back twice always with same error restoring app...

I asked to ChatGPT 5.0:

I’m on Cloudron trying to Update Vikunja app to 2.5.0 , but I get this error:

level=ERROR msg="Migration failed: migration 20260720120000 failed: cannot recreate the unique index on tasks (project_id, index) because 2 sets of duplicate values exist — remove the duplicates manually, then restart Vikunja"

what I’ve to do?

Then ChatGPT answered with MySql different queries, then I told:

I’m on postgres

Then gave me this answer:

For PostgreSQL, follow the same principle: keep one task in each duplicate set and assign new task indexes to the others.

1. Back up Vikunja

Create a manual Cloudron backup before modifying the database. Ideally stop Vikunja or ensure nobody is using it during the repair.

2. Connect to PostgreSQL

Open the Vikunja app’s Terminal and run:

psql "$CLOUDRON_POSTGRESQL_URL"

If that variable is unavailable:

PGPASSWORD="$CLOUDRON_POSTGRESQL_PASSWORD" psql \
  -h "$CLOUDRON_POSTGRESQL_HOST" \
  -p "$CLOUDRON_POSTGRESQL_PORT" \
  -U "$CLOUDRON_POSTGRESQL_USERNAME" \
  -d "$CLOUDRON_POSTGRESQL_DATABASE"

3. Inspect the duplicates

SELECT
    project_id,
    "index",
    COUNT(*) AS count,
    ARRAY_AGG(id ORDER BY id) AS task_ids
FROM tasks
GROUP BY project_id, "index"
HAVING COUNT(*) > 1
ORDER BY project_id, "index";

To also see task titles:

SELECT
    t.id,
    t.project_id,
    t."index",
    t.title
FROM tasks AS t
JOIN (
    SELECT project_id, "index"
    FROM tasks
    GROUP BY project_id, "index"
    HAVING COUNT(*) > 1
) AS d
  ON d.project_id = t.project_id
 AND d."index" = t."index"
ORDER BY t.project_id, t."index", t.id;

4. Automatically reassign the extra indexes

The following keeps the lowest task ID in each duplicate set unchanged and assigns unused indexes to the others:

BEGIN;

LOCK TABLE tasks IN ACCESS EXCLUSIVE MODE;

WITH ranked AS (
    SELECT
        id,
        project_id,
        "index",
        ROW_NUMBER() OVER (
            PARTITION BY project_id, "index"
            ORDER BY id
        ) AS duplicate_number
    FROM tasks
),
to_fix AS (
    SELECT
        id,
        project_id,
        ROW_NUMBER() OVER (
            PARTITION BY project_id
            ORDER BY "index", id
        ) AS new_offset
    FROM ranked
    WHERE duplicate_number > 1
),
project_max AS (
    SELECT
        project_id,
        COALESCE(MAX("index"), 0) AS max_index
    FROM tasks
    GROUP BY project_id
)
UPDATE tasks AS t
SET "index" = pm.max_index + f.new_offset
FROM to_fix AS f
JOIN project_max AS pm
  ON pm.project_id = f.project_id
WHERE t.id = f.id
RETURNING t.id, t.project_id, t."index", t.title;

COMMIT;

This does not delete tasks. It only changes the duplicate per-project task numbers.

5. Confirm the problem is fixed

SELECT project_id, "index", COUNT(*)
FROM tasks
GROUP BY project_id, "index"
HAVING COUNT(*) > 1;

It should return:

(0 rows)

Exit PostgreSQL:

\q

Then restart Vikunja and retry the Cloudron update to 2.5.0.

---

ChatGPT forgot to remember me to enble recovery mode because app was unreachable at moment, but I solved.

Thanks @humpty for your patience taking look into the problem.

@humpty thanks for your help.

Do you mean browser cache?

Cloudron app does not start after update...

@james No fixed at all...

Hi,

after Vikunja 2.5.0 update (io.vikunja.cloudronapp@1.25.0), app is not responding with this error:

level=ERROR msg="Migration failed: migration 20260720120000 failed: cannot recreate the unique index on tasks (project_id, index) because 2 sets of duplicate values exist — remove the duplicates manually, then restart Vikunja"

Any help would be great.

Thanks a lot

@girish take a look of this blocking list: https://perishablepress.com/ultimate-ai-block-list/

Hi all, another iOs client for Vikunja, also supports off-line mode:

https://marco308.github.io/mdone/
https://community.vikunja.io/t/mdone-a-native-ios-and-macos-app-for-vikunja/4548

Just received from Hetzner:

---

We would like to inform you that we will be increasing the prices for cloud servers effective 15 June 2026. This applies exclusively to new orders and rescales of existing servers. Cloud servers currently under contract are not affected by the price adjustment. This is intended to give you sufficient time to make any necessary adjustments, particularly with regard to automated server creation via API or integrations.

What is changing?

As part of the standardization of our product portfolio, we are increasing the prices of all Cloud plans. This price change is necessary due to the volatile hardware market.

Which products are affected?

The price adjustment applies to all newly ordered cloud servers and dedicated servers at all locations. However, web hosting products, managed servers, servers from the Server Auction, IPs, storage products, Load Balancers, Volumes, Snapshots, and Object Storage are not affected.

Why the change?

The price adjustment ensures that we will be able to continue to operate our infrastructure in a reliable, efficient, and sustainable manner. In particular, it takes into account the massive increase in procurement costs.

What does this mean for you?

Existing server contracts will, of course, keep their terms and conditions and remain active. The changes apply exclusively to new orders and rescales of existing servers.

We are aware that repeated price adjustments can be a challenge. Our commitment remains; we want to offer you stable and fair prices in the long term.

The transition will take effect on 15 June 2026. We will provide further details on the new rates on our website during the rollout.

We thank you for placing your trust in us, and we are confident that we will continue to offer our services at an competitive price-performance ratio.*

---

Note:

Existing server contracts will, of course, keep their terms and conditions and remain active. The changes apply exclusively to new orders and rescales of existing servers.

Have they learned lesson from latest price increase? Perhaps they suffered a significant loss on their contracts following the latest price hike, which also affected their previous contracts.

@jdaviescoates @joseph Thanks for your advice. I followed this guide: https://github.com/dani-garcia/vaultwarden/wiki/Using-the-MariaDB-(MySQL)-Backend#foreign-key-errors-collation-and-charset and problem now is fixed.

thanks a lot

Same problem here. Restored to 1.24.4 and stopped automatic updates.

@nebulon Yes, they still have ongoing problems... Even if they mark as “solved”, problem is not fixed.

This can affect Cloudron installations.

Just tried to install Cloudron again but...

Err:75 http://security.ubuntu.com/ubuntu noble-updates/main amd64 linux-firmware amd64 20240318.git3b128b60-0ubuntu2.26
  429  Too Many Requests [IP: 2620:2d:4000:1::103 80]
Fetched 220 MB in 5min 41s (643 kB/s)
E: Failed to fetch http://security.ubuntu.com/ubuntu/pool/main/l/linux-firmware/linux-firmware_20240318.git3b128b60-0ubuntu2.26_amd64.deb  429  Too Many Requests [IP: 2620:2d:4000:1::103 80]
E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?

@james Trying a second install, on previous broken Cloudron installation, will give this:

=> Updating apt and installing script dependencies
=> Waiting for 30s for existing apt/dpkg processes to finish...
=> Waiting for 30s for existing apt/dpkg processes to finish...
=> Waiting for 30s for existing apt/dpkg processes to finish...
=> Waiting for 30s for existing apt/dpkg processes to finish...
=> Waiting for 30s for existing apt/dpkg processes to finish...

while

tail -f /var/log/cloudron-setup.log

give this:

Running cloudron-setup with args : --

@james Yes, I know very well that Repos is not managed by Cloudron, but whole process can interfere with Cloudron installations and be critical specially when configuring a new Cloudron in a case of disaster recovery or switching Cloudron instances with backup/recovery, or simply when installing a new Cloudron instance.

In fact, if repository cannot be reached, Cloudron cannot be installed.

Hetzner give a good guide on how to switch, and also their repository is always reachable, fast and stable.

How @robi suggested, it could be interesting to add to Cloudron install script some strings to avoid this kind of issue.

Could be a speedy mirror or ability to pass parameter in ./cloudron-setup eg. ./cloudron-setup -h or something where user can chose wich mirror to use. -h = Hetzner, and so on.

At this point, script will manage all the whole process and continue installation of packages and Cloudron instance.

Ubuntu Repository is often slow and unstable.

In last months I had several time same problem: unreachable, overloaded...

In Cloudron installation script it could be interesting to select (or auto shift based on ping) a different mirror as an alternative.

This is a real time video record of the speed today:

Err:75 http://security.ubuntu.com/ubuntu noble-updates/main amd64 linux-firmware amd64 20240318.git3b128b60-0ubuntu2.26
  429  Too Many Requests [IP: 185.125.190.82 80]
Fetched 291 MB in 14min 1s (346 kB/s)
E: Failed to fetch http://security.ubuntu.com/ubuntu/pool/main/l/linux-firmware/linux-firmware_20240318.git3b128b60-0ubuntu2.26_amd64.deb  429  Too Many Requests [IP: 185.125.190.82 80]
E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?

And then result is:

=> Installing base dependencies (this takes some time) ...Init script failed. See /var/log/cloudron-setup.log for details

@james Yes, this is a great find. Thanks a lot for your cooperation.

In email service’s logs no any log...

Whenever you want, I can reproduce issue and I can send you raw log.

Keep me posted.