Containers are beautiful… backups are pain. So I built a “dummy” app to host DB add-ons (securely).

[DualOSWinWiz]

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.*

[robi]

Great creativity and idea.

Reminds me of a startup I did, where the premise was separation of config, app and data where then any app can be yanked out of a system no matter where it runs and migrated anywhere else you please.

@staff should like the idea since it's close to their platform thinking and how they handle shared DB services.

This makes it modular enough for all the DBs we don't have yet, which people are often requesting.

It does need a minimal UI for health checks which could be adapted from our VPN app to handle DB configuration ACLs.

Share the repo when ready and you may get more collaborations and deployment via CCAI for additional testing.

[DualOSWinWiz]

This post is deleted!

[robi]

@DualOSWinWiz I did not ask for that.

[timconsidine]

@DualOSWinWiz I have a vague recollection that someone created an app with a dummy page to return a 200 response and ran Postgres DB under the hood, so other apps could connect to a segregated standalone Postgres data store, like some hosting providers offer.

1. Is your app similar or did I miss the point partially or entirely ?
2. I searched for the app or thread lurking in undisturbed corners of my mind but I’m on a mobile screen and did not find it. Wood for trees or it’s been deleted.
3. That app did not make it into the AppStore, so maybe it did not align with Cloudron’s direction at the time. Now : who knows ? I’m sure (@)staff will chip in when they have time.

[DualOSWinWiz]

@timconsidine Yes similar idea just DB addon

[nebulon]

We do have some vague ideas about adding essentially headless "apps" like databases, pure APIs, ... in 2026. Basically some more PaaS bits. Currently as mentioned here, we have designed everything around apps which should have a webui, so this is certainly not ideal for many use-cases.

There are some known missing bits in Cloudron to properly support like a database service. For example to provide reliable backup/restore points, we have to signal the process to flush all caches to disk before cutting a backup. This is what is done in Cloudron services right now, but for apps, we don't have this yet (with the exception for some optimizations for apps using sqlite)