I think if we do a simple IP whitelist/blocklist, the onus is on the Cloudron admin to manage all this. Users come and go, move between places, have dynamic IPs etc. But sure, this can be added to, if it's seen as beneficial over VPN.
Vurrent VPN system is perfect and gives a certain level of granularity.
One question: why did you guys opt for this VPN protection vs simply allowing users to define a white list of source IPs or domains from where the access would be allowed? Would be much simpler and not require the VPN hassle (no matter on an endpoint or a router).
I tried to use Blocked IPs & ranges feature adding all IP’s list unless the specified IP but VPS became unresponsive.
I agree to enable an allow list that, when enabled, blocks everything unless specific IP.
@jdaviescoates Thanks a lot, how I can run this without installing Cloudron CLI? Eg. directly from App command line.
I think if this problem is on scale, devs should release a fix also to address this specific issue...
Edit:
@jdaviescoates I installed Cloudron CLI and I used this string that you posted above:
for a in $(cloudron list | awk '$5=="stopped" && $3=="org.wordpress.unmanaged.cloudronapp@4.0.0" {print $1}'); do cloudron start --app "$a" && cloudron update --app "$a" --appstore-id org.wordpress.unmanaged.cloudronapp@3.17.0 --force; done
I have:
WordPress (Developer) 7.0
Package version
org.wordpress.unmanaged.cloudronapp@4.0.0
The (only) one updated shows now:
WordPress (Developer) 7.1.3
Package version
org.wordpress.unmanaged.cloudronapp@3.17.0
My question is: if there is an available update, why if I hit "check for updates” nothing happens?
Thanks a lot
Hi @girish on a single Wordpress Developer instance I was asked to update to org.wordpress.unmanaged.cloudronapp@3.17.0 and I updated.
But all other Wordpress Developer instances, even if I hit "check updates”, nothing happens...
@jdaviescoates Another “workaround” could be to install VPN app and mark as required to access to all installed application. What do you think? Could be a temporary workaround to avoid to stop every app?
@nebulon Thanks Nebulon 
and thanks for all your efforts
@girish Thanks a lot, I did manually. But I cannot figure out why not was automatically updated...
@girish on different Cloudron instances I ran
# dpkg-query -W -f 'installed: ${Version}\n' ca-certificates
I had older version, I updated.
Why wasn't it updated, even though Cloudron should have updated it?
I think something depends on 10.1.5 update... let’s wait for help
Do you manage login with Cloudron or with app itself?
Just to debug, please do this test:
go to
config.php in app root folder, then change auth_type to form:
'auth_type' => 'form',
then reboot
@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....
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.
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.
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.
Create a manual Cloudron backup before modifying the database. Ideally stop Vikunja or ensure nobody is using it during the repair.
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"
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;
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.
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.