Cloudron Forum

App package bug?

Similar behaviour on all instances.

Ghost app package: org.ghost.cloudronapp2@4.205.1

Oct 28 17:39:15 [2026-10-28 16:39:15] ERROR "POST /members/api/send-magic-link/" 400 3ms
Oct 28 17:39:15 
Oct 28 17:39:15 The request could not be understood.
Oct 28 17:39:15 2026-10-28T17:39:15+01:00 
Oct 28 17:39:15 Error ID:
Oct 28 17:39:15 7b4bd747-39c6-2sed-9873-45b34343cb09
Oct 28 17:39:15 2026-10-28T17:39:15+01:00 
Oct 28 17:39:15 ----------------------------------------
Oct 28 17:39:15 2026-10-28T17:39:15+01:00 
Oct 28 17:39:15 BadRequestError: The request could not be understood.
Oct 28 17:39:15 at verifyIntegrityToken (/home/cloudron/ghost/versions/6.72.0/core/server/services/members/middleware.js:332:15)
Oct 28 17:39:15 at Layer.handle [as handle_request] (/home/cloudron/ghost/versions/6.72.0/node_modules/.pnpm/express@4.22.3_supports-color@10.2.2/node_modules/express/lib/router/layer.js:95:5)
Oct 28 17:39:15 at next (/home/cloudron/ghost/versions/6.72.0/node_modules/.pnpm/express@4.22.3_supports-color@10.2.2/node_modules/express/lib/router/route.js:149:13)
Oct 28 17:39:15 at /home/cloudron/ghost/versions/6.72.0/node_modules/.pnpm/body-parser@1.20.8_supports-color@10.2.2/node_modules/body-parser/lib/read.js:137:5
Oct 28 17:39:15 at AsyncResource.runInAsyncScope (node:async_hooks:227:14)
Oct 28 17:39:15 at invokeCallback (/home/cloudron/ghost/versions/6.72.0/node_modules/.pnpm/raw-body@2.5.3/node_modules/raw-body/index.js:238:16)
Oct 28 17:39:15 at done (/home/cloudron/ghost/versions/6.72.0/node_modules/.pnpm/raw-body@2.5.3/node_modules/raw-body/index.js:227:7)
Oct 28 17:39:15 at IncomingMessage.onEnd (/home/cloudron/ghost/versions/6.72.0/node_modules/.pnpm/raw-body@2.5.3/node_modules/raw-body/index.js:287:7)
Oct 28 17:39:15 at IncomingMessage.emit (node:events:514:28)
Oct 28 17:39:15 at endReadableNT (node:internal/streams/readable:1783:12)
Oct 28 17:39:15 at process.processTicksAndRejections (node:internal/process/task_queues:90:21)

@jdaviescoates Last week, I learned about two options:

1. Apps that run protected by a VPN
2. Apps that run in recovery mode

Both options work. Option 2 is the right approach if a security vulnerability works on ports other than 80 and 443.

@bazinga Yes. Just to troubleshoot - “but to me, that sounds like a problem with the platform.”
If the basic steps work, we can move on - just like with, “Did you turn it off and on again?”

@bazinga Does a direct VPN connection between your computer and your Cloudron instance work?

@jdaviescoates as fas as i know:
2fauth
ampache
bookstack
castopod
dokuwiki
dolibarr
easyappointments
espocrm
firefly-iii
freescout
freshrss
glpi
grav
humhub
invoiceninja
jirafeau
kanboard
kimai
koel
leantime
limesurvey
lychee
matomo
mautic
mediawiki
monica
moodle
nextcloud
omeka-s
opodsync
osticket
piwigo
pixelfed
privatebin
roundcube
rss-bridge
shaarli
snappymail
snipeit
tachyon
tinytinyrss
wallabag
wallos
wordpress-developer
wordpress-managed
xbackbone
yourls

@marcusquinn I have no idea whether this is a packaging issue. Did you find some kind of “switch” to sync a mailbox? Opendesk hasn’t synced with a Cloudron mailbox for two hours now (no alias and without multiple domains). There’s no setting for the sync frequency or a manual sync option. How did you solve this?

Same thing with 2.26.0, but NOT with a fresh install.

@girish 2.24.0

Oct 15 20:40:50 2026-10-15T20:40:50+02:00 
Oct 15 20:40:50 createKey (stdout): Host: 3.2.5 | nix | Linux | undefined
Oct 15 20:40:50 2026-10-15T20:40:50+02:00 
Oct 15 20:40:50 createKey code: 1, signal: null
Oct 15 20:40:50 {
Oct 15 20:40:50 path: '/api/key/lolo',
Oct 15 20:40:50 status: 500,
Oct 15 20:40:50 error: HttpError: createKey exited with error 1 signal null
Oct 15 20:40:50 at createKey (file:///app/code/src/vpn.js:787:39)
Oct 15 20:40:50 at process.processTicksAndRejections (node:internal/process/task_queues:104:5) {
Oct 15 20:40:50 status: 500,
Oct 15 20:40:50 internalError: Error: createKey exited with error 1 signal null
Oct 15 20:40:50 at ChildProcess.<anonymous> (file:///app/code/src/vpn.js:167:23)
Oct 15 20:40:50 at ChildProcess.emit (node:events:514:28)
Oct 15 20:40:50 at ChildProcess._handle.onexit (node:internal/child_process:295:12) {
Oct 15 20:40:50 code: 1,
Oct 15 20:40:50 signal: null
Oct 15 20:40:50 },
Oct 15 20:40:50 details: null
Oct 15 20:40:50 }
Oct 15 20:40:50 }
Oct 15 20:40:51 GET /build.json 304 0.480 ms - -

VPN 2.24.0

@ekevu123 As I understand the app configuration, there are various “places” where available times for an appointment can be displayed (which affects the possible time slots when an appointment can be booked).

a) a connected calendar and
b) availability (working days and hours)

In short: the traditional way works with free time.

This works perfectly for 1:1 appointments with potential customers. They can choose from many available times in my calendar.

But a monthly webinar takes place on a fixed date each month (say, every first Tuesday of the month from 5:00 to 6:00 p.m.). Also, a monthly webinar is open to more than one customer (which is why I asked about the 1:n relationship).

At the moment, I’m having trouble setting up my calendar so that it only offers free times on the first Tuesday of each month from 5:00 to 6:00 p.m., because as I understand it, that’s exactly what the meeting type requires.

The way I see it, we need the exact opposite. Instead of using free time slots based on the connection between a calendar and availability, we need fixed appointments so that the new meeting type can use the 1:n relationship. Am I right?

@ekevu123 First quick test: It works like a charm. Cancellations, rescheduling … Next, I’ll take a closer look at the edge cases (what happens when there are no spots left, reminder mail to all participants …).

Two questions about this feature:

• Why is the number of available spots displayed? (or why to deal with spots?) In my use case (regular webinars), that’s not important to participants. It also reveals something I’d rather keep from the public (nobody’s interested in my webinar - so the maximum number of participants is shown for every session).

• Do you have a workflow in mind for configuring this “special event” (say, a monthly online meetup - every second Friday of the month from 5:00 to 6:00 p.m.) without adding sessions to a calendar just to show the available spots for the online meetup?

@ekevu123 Where? When? How? Found it. The Cloudron app is a little behind your repository.

price-wise: https://www.manitu.de/vserver/ & https://www.hosting.de/server/

Great. 75% done. What’s still missing? Redirecting to the correct domain.

Current setup:
Location = default location
Aliases = match the site configuration in Surfer
Redirects = redirect to the location

For a “real” multi-domain app, I need configuration options for this typical use case:
www.example.org
www.example.com

example.org redirects to www.example.org, and example.com redirects to www.example.com. As I understand it, that’s currently not possible.

@jdaviescoates The main thing is: I have no idea what happens if I delete the user. For example, a former teammate or freelancer who is no longer active (and won't be coming back, but was active in GitLab, for instance).
Another use case: Imagine employees on parental leave (usually 6 months or longer). They will be coming back, but shouldn't receive any notifications during their absence. Later on, they'll be active again

@joseph That's a good point. Regardless of the reason for having inactive users in the first place, another way to fix this would be a different dropdown layout:

• Active users (alphabetical)
• Inactive users (alphabetical and dimmed), listed below the active ones

@lukasp Multiple backup sites is only in the Max plan. If this is your subscription, you found a bug.

https://www.cloudron.io/pricing.html

e.g. in the mailbox owner, Only allow selected users, Operators ... dropdown.

In the app's file manager, I can browse and edit files. However, doing the same via /_admin doesn't allow for editing. This inconsistency is quite confusing.

@ekevu123 If you need real humans for testing, give me ping.