Cloudron Forum

xyOps is an open source workflow automation system with job scheduling, server monitoring, alerting and ticketing built in. It orchestrates work across a fleet of servers from a single web interface: chain jobs into visual workflows with conditional logic, schedule them with crontab syntax and blackout windows, watch progress live, and get alerted on server or custom metrics.

Jobs are executed by xySat, the lightweight worker agent, which installs on Linux, macOS, Windows and Docker with one command generated from the xyOps interface. Plugins can be written in any language that can speak JSON over STDIO, and the plugin marketplace ships integrations for Slack, Discord, AWS S3, OpenAI and more.

On Cloudron, this package runs the xyOps conductor - web interface, API, scheduler and database - plus, by default, a local xySat worker in the same container, so jobs can run without adding an external server first. Remote workers connect back through the app domain on port 443, so no extra ports need opening.

Features:

• Visual workflow builder with conditional branching
• Cron-style scheduling with blackout windows and job limits
• Live job tracking, output capture and log search
• Server and custom metric monitoring with alerting
• Built-in ticketing tied to jobs and alerts
• Plugin marketplace and a JSON-over-STDIO plugin API
• Secrets, API keys, webhooks and fine grained privileges

xyOps is the successor to Cronicle, by the same author, and is BSD 3-Clause licensed.

Packaging source: https://git.9wd.eu/apps/cloudron-xyops

Store listing: https://ca.cloudron.io/app/xyops

It is a more advanced alternative to Ctfreak which is already available on the Cloudron app store.

Exchange Webservices as as additional calendar type would be nice, but there does not seem to be something in elixir for this.

Yes, I have seen that as well. This comes from the cypht cardav client. Wenn that one is enabled it looks for a server at that address by default. So to get rid of the error either remove the carddav part from CYPHT_MODULES in .env or add the address of a carddav server.

PS: i have removed the module from the default configuration for the next release

@girish said:

Do we have concrete use cases? Maybe we should collect them and decide what is the best approach

It certainly always depends on the application one wants to use. I do remember some people requesting mailman as an app, but that was not possible because mailman wants mails directly delivered to it instead of to a mailbox.

One application that i currently use and could benefit from this would be ntfy, where you can also submit messages via smtp.

Another application that could benefit from this would be alternative mailservers like stalwart or the product from my employer if you need exchange like sync.

@girish said:
Each mailbox now has a capability to set up forwarding (same options as mailing list):

Looking forward to try out this new feature. Now that each mailbox has some settings, would it be possible to configure a different delivery for a given mailbox? Like some apps want mail delivered via pipe to a command, lmtp, or simply another internal smtp port in an app.

@LoudLemur said:

that particular host genuinely didn't have our exact base-image digest cached yet

This was probably the reason for the long download.

@LoudLemur said:

the install is still slow, because the whole 2.5GB has to be pushed to a registry and then pulled onto the Cloudron host every time.

Your ai is not reasoning correctly here. Since all cloudron app share the same base image these 2,5gb are already sitting on the cloudron system and only the layers you add during your app build are downloaded.

yes. I would not be surprised if the hickup comes from somewhere in the sql file. For the restore test you should first reset the failed migration to its previous state and extract the sql file from the old backup. There are instructions in the cloudron documentation for this.

@joseph That is it (source: I just tried it myself and directly deleted the app again)

Right you actually wrote that already. My next step would be to try to import the mysql directly from the shell.

The memory angle could also point to the host ram (any oom in dmesg?) or disk space issues. Although its not running long, so it cant be that big of a sql dump.

Anything in docker logs mysql?

Having a quick glance at the log, it says the import to the database fails. Have you also increased the memory for the MySQL service?

From my understanding the sync bundle is less moving parts and can work without the s3 bucket. But I haven’t looked to close into your repo yet, so I cannot say how you have solved this part.

I’m a long time Anytype user. But I have a subscription with them, so I am not an immediate candidate for a migration.

I have not tried the custom app, but the components in it are "only" the sync backend. Anytype does not provide a webclient unfortunately and everything goes through the desktop or mobile apps. How to use a self hosted backend is explained https://doc.anytype.io/anytype/data/sync-and-backup/self-host

@ultraviolet is there a particular reason why you went with the anytype components directly instead of the more leightweight https://github.com/grishy/any-sync-bundle/ ?

Did you change the secret to a custom value as instructed in the post install instructions?

A better thing to look into would be https://docs.renovatebot.com/. I think i have seen renovate config files in the cloudron app repositories as well in the past. With renovate you can get automatic merge request for the changed dependencies.

A working example can be found in this repo as well https://git.9wd.eu/apps/cloudron-cypht

@girish said:

The main issue is/was signing docker images

@girish

True, tags are mutable, so pulling by tag alone leaves you vulnerable if a registry is compromised.

Container signing verifies provenance (who built it), while referencing an image by digest (image@sha256:...) guarantees integrity (that it hasn't been altered). If the Cloudron app manifest explicitly pins container digests, you effectively get both: Cloudron verifies the authenticity of the app manifest, and the digest ensures the container pulled from the registry hasn't been tampered with.

As a quick note on mirroring: docker tag & push actually preserves digests in most OCI registries, but using tools like crane copy or skopeo is definitely the right approach since they transfer images directly between registries without local daemon overhead or pulling down heavy layers.

Regarding experience with container signing: the modern standard is Cosign (part of Sigstore). Because Cosign stores signatures as standard OCI artifacts inside the registry, it works out-of-the-box with almost every modern registry today (Docker Hub, GHCR, Harbor, AWS ECR, etc.) without requiring special server-side setup.

@timconsidine said:

Reputation of packager and security of a particular CloudronVersions.json are different issues.

Yes, exactly this. Since everything is isolated on cloudron the damage is mostly in the compromised app itself. But it is a valid scenario.

@robi said:

Does it need solving? Or is the stepping stone from CA to Official App enough?

Not all custom apps may want to be listed in the official store. I do see the possibility of private app stores with pay walled apps. @luckow posted such a store a while ago.

I recently experimented with the CloudronVersions.json file and the community app store. It's quite convenient: add the URL to the JSON file at installation, and the app gets the same automatic backups and updates as official apps.

To be clear — these are third-party apps, use at your own risk, and anyone installing one should review it beforehand (I know most won't in practice).

That said, there's a security gap worth discussing:

Package repositories typically sign their manifests to prevent tampering — if someone modifies a package after the maintainer publishes it, the signature breaks and clients refuse to install it.

CloudronVersions.json has no such signature. This means:

1. A maintainer uploads a legitimate manifest.
2. A third party (or a compromised host) modifies the JSON file after the fact.
3. Users downloading the app get a potentially compromised version — with no warning.

Automatic updates make this worse: once you trust a URL, every future update is pulled from that same unverified source.

I already raised this with the Cloudron team directly. Their position is that since this is a third-party feature, adding signatures is out of scope for them. I understand the reasoning, but I wanted to bring it to the community to get a sense of whether others share this concern.

https://github.com/OrcVole/windmill-cloudron/blob/main/scripts/make-cloudron-versions.py

That was something I also noticed in the other repo you posted. instead of writing your own script to create the cloudronversion.json you should use the cloudron cli for this. There is also an ai skill that helps along.

@andreasdueren @joseph overall the upstream project does not seem to be very good with database topics. I recently wanted to create some workflows in my older installation and first needed to fix some indexes as well before the app responded successfully.

My installation ran into this upgrade issue as well, thanks for the commands. Instead of running the last database migrations myself I just disabled the recovery mode and restarted the app.