Lots more done on this recently, including packaging as a Cloudron app. More on that here:

• https://forum.cloudron.io/topic/15249/ai-devops-opencode-alternative-to-_claw-bots

cross-linking:

• https://forum.cloudron.io/topic/15249/ai-devops-opencode-alternative-to-_claw-bots

I prototyped a Cloudron app for this here:

• https://github.com/marcusquinn/aidevops-cloudron-app

(made with aidevops)

you can of course still use it safely, locally — which I do and recommend — but if you want a cloudron instance for any reason, this should also work

look at my GitHub activity if you want to see what it's capable of:

• https://github.com/marcusquinn

@robi Cool! Thanks for the mention!

Yup, we all love free stuff.

aidevops.sh is fully open-source, practice what I preach

Best way to explain it is to try it, as it's designed to explain itself.

I use it personally ever day, so evolves as fast as I can to share capabilities.

Let us know how you get on...

Problem

When using the Nextcloud Tasks app, attempting to create a new task list fails with: "An error occurred, unable to create the list."

Creating tasks via Apple Reminders (CalDAV sync) also silently fails — new lists simply disappear.

Deleting existing task lists and emptying the trash temporarily fixes the issue, but it returns once you have enough lists again.

Root Cause

Nextcloud 32.x introduced a RateLimitingPlugin in the DAV app (apps/dav/lib/CalDAV/Security/RateLimitingPlugin.php) that enforces a hard limit of 30 calendars + subscriptions per user via the dav.maximumCalendarsSubscriptions app config setting (default: 30).

Two issues with this limit:

1. The default of 30 is too low for users who use the Tasks app heavily (e.g., project management with one task list per project). Each task list is a CalDAV calendar, so 28 project lists + a personal calendar + a birthday calendar = 30 = limit reached.
2. Trashed calendars count toward the limit. The getCalendarsForUserCount() method in CalDavBackend.php has no deleted_at filter, so calendars in the trash still count. This is arguably a bug — trashed items shouldn't block creation of new ones.

There's also a rate limit of 10 calendar creations per hour (dav.rateLimitCalendarCreation), which can be hit when setting up multiple projects.

Fix

Increase the calendar+subscription limit (default: 30)

occ config:app:set dav maximumCalendarsSubscriptions --value=999

Or disable the limit entirely

occ config:app:set dav maximumCalendarsSubscriptions --value=-1

Optionally increase the rate limit (default: 10 per hour)

occ config:app:set dav rateLimitCalendarCreation --value=50
Suggestion for Cloudron
Consider either:

• Increasing the default maximumCalendarsSubscriptions to 999 in the Cloudron Nextcloud package's start.sh
• Or documenting this limit in the Cloudron Nextcloud docs
  The error message from the Tasks app ("An error occurred, unable to create the list") gives no indication that a calendar limit has been reached, making this very difficult to diagnose.

Environment: Cloudron Nextcloud package 5.6.7 (Nextcloud 32.0.6), Tasks app 0.17.1

@jdaviescoates can recommend opencode.ai, even includes some good free models to get you started.

@timconsidine thanks for testing. Refactored so OICD is an optional extra, plus other changes to the whole approach. README should explain.

@robi looks like a dead website and something to do with bitcoin? not seeing a fit, but make a wishlist post if you think i'm missing something

Overall, the app seems to be the best of the bunch for ticking all opsec boxes.

I can see this becoming the main way AI agents & users communicate, too, as the cli is very friendly, mature, and versatile.

the SMP server is a good candidate for packaging as an app, should be simple, and help further the decentralisation:

• https://simplex.chat/docs/server.html

Related: https://forum.cloudron.io/topic/15109/tls-passthrough-option-for-apps-requiring-end-to-end-tls

Update on the Cloudron NetBird package
The packaging scaffold at https://github.com/marcusquinn/cloudron-netbird-app is fairly complete -- it uses the combined netbird-server binary behind an internal nginx that consolidates all the path-based routing (gRPC, WebSocket, REST API, dashboard) onto a single HTTP port for Cloudron's reverse proxy.
What works (in theory -- needs real-world testing):

• Management API, Signal, Relay, STUN, and Dashboard all in one container
• Cloudron SSO via the OIDC addon
• Cloudron's built-in TURN server for NAT traversal relay
• PostgreSQL via Cloudron addon
• Backup/restore of all persistent state
  The one feature that can't work on Cloudron: NetBird's Reverse Proxy (v0.65+)
  This is NetBird's newer feature that exposes internal services on mesh peers to the public internet with automatic TLS. It requires Traefik with TLS passthrough -- the NetBird proxy container needs to terminate TLS itself. Cloudron's nginx terminates TLS before traffic reaches the app, so there's no way to pass through the raw TLS connection that NetBird's proxy needs.
  I looked at whether alpine/socat (TCP socket forwarder) could bridge this gap, but it can't -- the problem is Layer 7 (HTTP path routing, gRPC protocol handling, TLS termination order), not Layer 4 (TCP forwarding). socat only does port-to-port TCP forwarding and has no understanding of HTTP paths, gRPC, or WebSocket upgrade headers.
  This doesn't affect the core VPN functionality at all -- peer-to-peer WireGuard tunnels, NAT traversal, access control, DNS, network routes, and the management dashboard all work fine without it. The reverse proxy is an optional add-on for publicly exposing internal services.

What's needed next:

1. Testing on a real Cloudron instance (I haven't done this yet -- the packaging is based on docs and the combined container architecture)
2. Verifying the internal nginx correctly handles the gRPC h2c proxying that Signal and Management need
3. End-to-end OIDC flow testing with Cloudron SSO
4. TURN relay testing for peers behind strict NAT
   If anyone wants to help test, the repo has a full testing checklist in the README. Would be great to get this into the Cloudron App Store.

feedback welcome!

(Opus wrote this for me )

The Problem

Some self-hosted applications need to handle TLS termination themselves rather than having the reverse proxy terminate it. Currently, Cloudron's nginx always terminates TLS before traffic reaches the app container. This makes it impossible to package apps that require TLS passthrough.

Real-World Examples

• NetBird (WireGuard mesh VPN) -- the reverse proxy feature requires Traefik with TLS passthrough so the netbird-proxy container can terminate TLS and issue its own per-service certificates via ACME. I'm currently packaging NetBird for Cloudron (cloudron-netbird-app) and everything works except this one feature.
• Matrix Synapse -- federation requires the server to present its own TLS certificate for server-to-server authentication.
• XMPP servers -- similar federation TLS requirements.
• Any app with built-in ACME -- apps that manage their own Let's Encrypt certificates (e.g., Caddy-based apps, Traefik-based stacks).

What I'm Requesting

A manifest-level option to enable TLS passthrough for a specific app, something like:

{
  "tlsPassthrough": true
}

When enabled, Cloudron's nginx would use ssl_preread and proxy_pass to forward the raw TLS stream to the app container based on SNI, without terminating it. The app would then handle TLS termination itself.
nginx supports this natively via the stream module with ssl_preread:

stream {
    map $ssl_preread_server_name $backend {
        netbird.example.com  netbird-container:443;
        default              normal-https-handling;
    }
    server {
        listen 443;
        ssl_preread on;
        proxy_pass $backend;
    }
}

Considerations

• This would only apply to apps that explicitly opt in via the manifest.
• The tls addon already provides cert/key files to apps -- TLS passthrough is the complementary feature for apps that need full control.
• It could coexist with the current nginx setup: most apps continue with normal TLS termination, only passthrough-enabled apps get the raw stream.
• The tcpPorts manifest option already demonstrates that Cloudron can expose non-HTTP ports per app -- this would be the HTTPS equivalent.

Impact

This would unblock packaging for a meaningful set of applications that currently can't work on Cloudron due to the TLS termination architecture. It would also make Cloudron more competitive with platforms like Coolify and Cosmos that support Traefik-based deployments.
Happy to discuss implementation details or help test if this gets picked up.

1st draft packaging this, if anyone that know's more wants to test:

• https://github.com/marcusquinn/cloudron-netbird-app

Revisited all of these alternatives.

Netbird is the clear winner for me. Has my recommendation!

@LoudLemur has its own thread:

• https://forum.cloudron.io/topic/14958/agent-zero-a-personal-organic-agentic-framework-that-grows-and-learns-with-you

Just found this. Works great!

@timconsidine ask your AI assistant to help with migration so you don't lose anything from Docker Desktop.

might not be relevant, but my bug-bear with Element Desktop and Mobile is they don't seem to support multiple servers, like Nextcloud Apps do.

The only alts I could find that do:

• https://schildi.chat/
• https://fluffy.chat/

@DualOSWinWiz sure, you could still do all that on one device.

Might be a useful skill to add into your mix:

• https://www.aitmpl.com/component/skill/invoice-organizer

@DualOSWinWiz exactly the kind of thing this is for — go for it!