Cloudron Forum

@james said in What's coming in 9.1:

Hello @DualOSWinWiz
Yes you can also run custom apps that are just databases.

So this meant their will be a port mapping facility as well great i dont know if its already their. I am anxious to see how backups and restore will handle the active connection to database.

@girish hey does this include databases containers like Postgress, MySQl, Mongodb, sql server etc? or databases still works as an addon? We need standalone database containers.

i am interested in Extended license but client's requirement is recording should be enabled across the board. is this something you can do in near future? we can talk in Direct Message as well

@girish Cloudron needs this please put it in priority apps i am using it and its way better then n8n where ai related automations are not the priority

@MiroTalk its a intresting solution i use twilio for some telehealth apps my client's biggest requirement is recording meant auto record no end user side option to start or stop recording and push to secure object storage is this something is possible if yes then we might have an opertunity to extend beyond twilio. Regards

I think tacticalrmm https://github.com/amidaware/tacticalrmm is a better qll in one solution it has messh and patch management as well i deployed it separately as it has 3 different apps. Api.xxx.xx , mesh.xxx.xx and rmm.xxx.xx and superadmin has to setup QR code while installation

Recently i gave up on Chat gpt pro subscription as the model seems like a chatty person and real work is sub par it tries to do everything immediately even though you ask to first understand requirements and blah blah blah jo matter how good the prompt is it looses easily i used abusive but nothing worked same thing with google gemini ultra. I found a better approach where i hosted typingmind on clodron surfer app and using anthropic and gemini and openai api keys.

So far the results are anthropic is still better when it comes to development and context but its expensive but if i see the time saved by going back and forth with subscription models this thing still works better. I moved on already. Now my new project is to make ide directly connect with my blackwell 6000 i created a heavy workstation whcih is quite heavy and will surely try to use that in future

@girish This makes a lot of sense for HashiCorp Vault, since it acts as a central trust component and supplies credentials to applications hosted separately. It also fits reasonably well for Uptime Kuma, where servers send heartbeat signals, though that’s a lighter use case. Another strong case is when Cloudron itself is used as the OIDC provider for other applications.

My Thoughts (Semi-Enterprise Use-Case Perspective)

After following this discussion and validating things hands-on, I think it’s important to state this clearly for anyone evaluating Cloudron for enterprise or internal business systems:

Cloudron is no longer positioning itself as a platform for business-grade internal applications.

This conclusion isn’t based on speculation—it’s based on both practical experience and the absence of signals to the contrary.

Cloudron’s strongest advantage remains unquestionable:

First-class backups and restores

Extremely fast disaster recovery

Very low operational overhead

From a DR standpoint, it’s excellent.

However, once you move beyond personal tools into real internal systems—admin panels, dashboards, workflow backends, data-heavy apps—the platform shows structural limits:

The database addon model is not reliable or predictable enough for serious internal workloads.

There is no visible roadmap or guidance for supporting internal business applications.

Community attempts to bridge this gap (e.g., packaging tools like Appsmith) receive no meaningful feedback or direction.

This thread itself has seen no response from Cloudron staff, which implicitly communicates priorities even if not stated explicitly.

Silence is also a signal.

At the same time, tools many Cloudron users depend on—n8n being a prime example—are clearly shifting toward AI-centric workflows, not semi-enterprise operational platforms. That’s a valid direction, but it leaves a gap Cloudron is not attempting to fill.

The practical takeaway is straightforward:

Cloudron excels at homelab, personal services, and lightweight internal tools.

Cloudron is not a good long-term foundation for enterprise-style internal platforms.

For those use cases, a more sustainable architecture is:

Direct container orchestration (Portainer / Docker / Kubernetes)

Explicit ownership of backup, restore, and object-storage workflows

Fewer platform assumptions, more operational control

This isn’t about frustration or dissatisfaction—it’s about alignment.

Cloudron has chosen a direction.
Cloudron staff engagement (or lack thereof) makes the priorities clear.
Enterprise users should plan accordingly instead of trying to force the platform into a role it no longer appears to target.

i went into a problem if DB is accessed by 3rd party the backup failed with error as its accessed by someone else @joseph @girish any thoughts can we force db to close all connections at time of backup request came kind of like a script in dummy application

@james said in Cloudron App Install Update Error Bug:

Hello @dualoswinwiz

Please use registry.docker.com as the docker hub server address.
This should resolve the issue.

i was using like this registry.hub.docker.com --- changing this to registry.docker.com solved the problem

@joseph @girish

On one Cloudron instance, both new app installs and existing app updates fail with Docker registry / image pull errors.
Another Cloudron instance (similar setup) does not show this issue.

After investigation, the failures occur only when Docker registry credentials are saved in Cloudron settings. Rebooting the server had no effect. Removing the saved Docker registry credentials immediately fixes installs and updates.

This affects normal operations like routine app upgrades and fresh deployments.

⸻

Steps to reproduce
1. Go to Cloudron Settings → Docker Registries
2. Save Docker registry credentials (e.g., Docker Hub or private registry)
3. Attempt to:
• Install a new app or
• Update an existing app
4. Operation fails during image pull
5. Remove saved Docker registry credentials
6. Retry install/update → succeeds

⸻

Logs

App install / update failure (sanitized):

Error: pull access denied for <CLOUDRON_IMAGE>,
repository does not exist or may require authorization:
server message: insufficient_scope: authorization failed

Error response from daemon:
unauthorized: authentication required

Docker daemon log:

time="2025-01-02T11:24:08Z" level=error
msg="Handler for POST /v1.44/images/create returned error:
unauthorized: authentication required"

Cloudron apptask log:

TaskError: Error pulling image <CLOUDRON_IMAGE>:<TAG>
exit status 1
at ChildProcess.<anonymous> (/home/yellowtent/box/src/docker.js:312:23)

⸻

Troubleshooting Already Performed
• Server reboot
• Retried install/update multiple times
• Compared with another Cloudron instance (working)
• Removed Docker registry credentials → issue resolved immediately

⸻

System Details

Generate Diagnostics Data

Not generated yet. Can provide if requested.

⸻

Cloudron Version

9.0.15

⸻

Ubuntu Version

Distributor ID: Ubuntu
Description: Ubuntu 24.04.2 LTS
Release: 24.04
Codename: noble
Kernel: Linux 6.8.0-90-generic

⸻

Cloudron installation method
• ISO Image

⸻

Output of cloudron-support --troubleshoot

Vendor: Generic
Linux: 6.8.0-90-generic
Ubuntu: noble 24.04
[OK] docker is running
[OK] docker version is correct
[OK] nginx is running
[OK] dashboard cert is valid
[OK] dashboard is reachable
[OK] box v9.0.15 is running

⸻

Additional notes / hypothesis

This looks like a registry credential scoping or precedence issue, where user-saved Docker credentials are applied globally and interfere with Cloudron’s own image pulls, affecting both installs and updates.

i was hardening it here is the repository link and tag

samcorepa/appsmith-cloudron-ce:20251230-135540

@timconsidine said in Appsmith:

@DualOSWinWiz can you check your repo and docker image links

samcorepa/appsmith-cloudron-ce:20251230-135540

@timconsidine i was hardening the images according to Docker Hub Scout let me public it please wait few moments

@joseph tried to DM you but its disabled i can share with you in DM message as my repository is Private

@nebulon so this meant DB backups are not accurate for the time being with this approach?

@timconsidine Yes similar idea just DB addon

Hey Cloudron folks

I’ve been enjoying the romance of containerization: reproducible builds, clean deployments, upgrades that don’t feel like surgery… and then backups show up and remind you that life is suffering

Containers: the honeymoon

Everything is clean and modular until you need to answer:

• “where exactly is the data?”
• “how do I restore this reliably?”
• “what happens when I migrate versions?”

In normal Docker-land, backup/restore often becomes a DIY project that turns into a part-time job.

Cloudron’s superpower

This is why I love Cloudron: backup and restore is a one-click reality, not a wish. That’s an insanely underrated feature when you’re running real systems.

The limitation that pushed me into… creativity

Cloudron is very app-centric (makes sense). But sometimes I want a “service-style” pattern:

“I want a database I can reuse across workflows/apps, and I want Cloudron’s backup/restore magic applied to it.”

So I tried a slightly funny but practical idea:

The “dummy app” approach

I created a minimal “dummy” Cloudron app whose job is essentially:

• satisfy the platform’s app model
• stay intentionally low-surface-area externally
• act as a stable anchor for database add-ons that other apps (like n8n) can consume

Basically:

This app is mostly paperwork… but the paperwork unlocks the good stuff.

Result so far: MongoDB is live

MongoDB is implemented and successfully connected (tested from my workflows). That’s the milestone I wanted before even thinking about expanding the idea.

Security posture (high level, no implementation details)

Because “shared database” can be great or disastrous depending on discipline, I treated security as the main requirement:

1) Strong auth hygiene

• 2FA enabled across Cloudron + n8n
• single-admin mindset where possible
• no password reuse (password manager)
• unique credentials per service, rotatable by design

2) Minimal public footprint

• the dummy app isn’t a UI product; it’s intentionally not a “new dashboard to attack”
• the goal is: tiny external surface, strict internal usage

3) Network isolation assumptions

• database access is treated as internal and controlled
• the design intent is “only approved apps/workflows can talk to it,” not open inbound internet reachability

4) Secrets stay out of images/repos

• credentials are handled as runtime secrets, not baked into artifacts
• no “oops I committed the keys” situations

5) Restore-first thinking

• backups are only real if restores are realistic
• the whole point is to use Cloudron’s strengths for recovery predictability

Why I’m sharing

This pattern could be useful for anyone who wants:

• Cloudron-grade backup/restore applied to shared data services
• stronger foundations for automation stacks like n8n
• less bespoke backup scripting across random containers

Questions for the community

1. Does this align with Cloudron’s model, or does it feel like a hack that shouldn’t be encouraged?
2. Any security pitfalls you’d specifically watch for in a “shared DB service” pattern?
3. If this became a community-maintained “DB service anchor” app, would you use it?

Thanks — and yes, I’m fully aware I created an app whose primary feature is “existing”… but it’s existing securely, with backups, and that’s kind of the point

Signature: Drafted with help from my AI assistant, because life is short and nobody has time to write essays when there are containers to babysit.*