Cloudron Forum

I would like to know, why Cloudron has a snapshot folder in the backup and a folder for each daily backup. This seems to be redundant, but surely does make a lot of sense. But, how does it work? I searched the forums, but did not find a discussion about this. Maybe it's to obvious? Would love to understand this miracle...

Hi everyone,

I see that the Tinybird integration is not yet supported in the current Ghost package and its status is currently “not possible” – which I can understand, since it officially works only through the Docker deploy setup.

What I also notice: Tinybird has now become the official analytics backend for Ghost 6.x and provides cookie‑less real‑time insights, which is a genuine added value for many publishers.

For many of us who use Ghost in production and would appreciate Ghost Analytics in the dashboard, an optional Ghost app variant on Cloudron with Tinybird support would be a great benefit – not as the default, but as an additional app variant with an analytics profile.

This could make Cloudron Ghost even more attractive without replacing the existing simple Ghost app, allowing publishers to use native analytics without switching to Ghost(Pro).

I think it would be great if the team could take a quick look at this, or if other users could also signal their interest.

@girish Thank you for this profound explanation. It's great that you are using Hardlinks. I guess, that's a real space and time saver. I did my first restores with Cloudron via the UI yesterday.

A) What does Cloudron internally use for the restore? Snapshot vs. Timestamp?

B) What could/should anyone use to restore without Cloudron? Snapshot vs. Timestamp?

This should be different, to make sense...

As far as understand, A) is Snapshot and B) is Timestamp. Right?

Hello @james and @zonzonzon

I now know the reason: Stopped apps are not backed up. Didn't know that. I will have to start them for inclusion in the backup.

@james

Thanks for your attention to my two issues (with builder & registry). It's really much appreciated. But, I decided to use an external builder and an external registry and succeeded in implementing a custom app in Cloudron this way. I wanted to give you some feedback with the two threads and hoped for a quick solution. But I did move on and will stay on this route for this project. But maybe later, I will try Cloudron Builder and Cloudron Registry again. At the moment, I solved my problem with other tools. Thank you!

Yes, I have three backup destinations. But, I see und understand that's not a good idea to do multiple backups at a time... My server is not on limits (CPU 5%, RAM 33%, Disk I/O and Network I/O are low). I think, it will run through, but it's slower than doing the backups one at a time. But the reason seems to be the "lock" of Apps by Cloudron Backup. Will not repeat that... But for now, I will let the system find it's way during the night.

Hello @james

I investigated further and it has been just a copy of my backup storage box (snapshot + data folders) in the folder /home/yellowtent/appsdata/$APPID. I deleted all the folders that do belong to the backup and not to the app. Of course, everything works smooth now. Thank you!

Also matomo and umami and many others work with Ghost. It's just the native integration in the dashboard of Ghost that makes it interesting.

Hello Cloudron team and community,

I would like to report an issue I ran into with the Docker Remote Builder, which appears to be a structural limitation rather than a configuration mistake. I’m posting this both to make you aware of it and to ask whether there is a recommended solution or workaround.

Summary

When using the Docker Remote Builder to build and push an image to a private Cloudron Docker Registry, the build succeeds, but the push consistently fails with:

no basic auth credentials

From extensive debugging, this appears to be caused by the fact that Docker cannot persist or access registry credentials, because:

• both /root and /home/cloudron are read-only
• DOCKER_CONFIG cannot be set via environment variables
• the builder does not bridge /app/data/docker.json into a Docker-readable config.json
  As a result, Docker has no place to read credentials from when executing docker push.

---

Environment

• Cloudron (latest stable)
• Docker Remote Builder (latest available via Cloudron App Store)
• Cloudron Docker Registry
• Private registry user: managed by Cloudron user management
• Cloudflare proxy disabled (DNS-only) for builder. and registry. subdomains

---

What works

• cloudron build login succeeds (token accepted)
• Image builds successfully:

Successfully built <image-id>
Successfully tagged registry.example.org/user/image:tag

• Registry is reachable
• Credentials are correct (verified manually)

---

What fails

Push always fails immediately:

The push refers to repository [registry.example.org/user/image]
Preparing <layer-id>
no basic auth credentials

Builder logs confirm the same.

Key findings from debugging

1. The builder runs as user cloudron:

exec gosu cloudron:cloudron /app/code/app.js

2. Both of these locations are read-only:

   • /root/.docker
   • /home/cloudron/.docker

3. Attempting manual login confirms this:

docker login registry.example.org -u <user>
# Error: mkdir /root/.docker: read-only file system

4. Setting DOCKER_CONFIG=/app/data/.dockerdoes work when done manually in the container, but:

   • there is no supported way to inject environment variables
   • /app/code/start.sh does not source an env.sh
   • therefore the build service process itself never sees DOCKER_CONFIG

5. /app/data/docker.json (in both formats tried):

   • Cloudron registry format
   • Docker auths format
     …is not consumed by Docker during the push step.

---

Conclusion

In this setup, the Docker Remote Builder:

• knows the registry credentials
• but cannot provide them to Docker in a usable way
• resulting in an unavoidable authentication failure during docker push
  This makes it impossible (or at least unreliable) to use the Remote Builder to push images to a private Cloudron registry in this configuration.

---

Questions

1. Is this a known limitation of the current Docker Remote Builder?

2. Is there a supported way to:

   • set DOCKER_CONFIG, or
   • make a writable Docker config available to the builder process?

3. Is the recommended approach instead to:

   • build externally (local / CI)
   • push to the Cloudron registry
   • and use Cloudron only for deployment?

I’d be happy to provide more logs or details if helpful.

Thank you for Cloudron overall – it’s a great platform, and I hope this feedback helps improve the build workflow.

Best regards
miednr

When choosing backup everything, only 10 of 19 Apps are being backed up. What could be the reason?

In cloudron-support --troubleshoot everything is OK.

@james I generated one in the builder, that was stored in tokendb.json.

I got an idea, but I am not sure...:

I have three backups of the whole system at the same time. Two are stuck on WordPress and the third is very slow progressing on the same WordPress. I guess, the "lock" means, that the other two backups wait for the third process to "unlock" their "lock" on that App. Is this true? I start to understand. But, why is this the default behavior?

That is a WordPress (Dev).

Thanks @james

Cloudron Version is 9.0.17 and the logs do have repeated entries like that:

Feb 07 20:30:16 box:locks Attempt 824 failed. Will retry: Locked by 652
Feb 07 20:30:26 box:locks Attempt 1 failed. Will retry: Locked by 652
Feb 07 20:30:26 box:locks Attempt 825 failed. Will retry: Locked by 652
Feb 07 20:30:36 box:locks Attempt 1 failed. Will retry: Locked by 652
Feb 07 20:30:36 box:locks Attempt 826 failed. Will retry: Locked by 652

Last lines before that are:
2026-02-07T17:12:37.003Z box:backuptask copy: copied backupinfo successfully to 2026-02-07-171219-870/app_xyz.domain.com_v1.0.1.backupinfo
2026-02-07T17:12:37.007Z box:backuptask fullBackup: app xyz.domain.com backup finished. Took 1.105 seconds
2026-02-07T17:12:37.011Z box:locks write: current locks: {"full_backup_task_XYZ":null,"app_backup_XYZ":"652","full_backup_task_XYZ":null}
2026-02-07T17:12:37.011Z box:locks release: app_backup_XYZ
2026-02-07T17:12:37.011Z box:tasks updating task 653 with: {"percent":39.095238095238095,"message":"Backing up domain.com (8/18). Waiting for lock"}

First I thought this was related to my storage, but it also happens with the local backup (SSD).

My Ubuntu takes 309 GB, my Docker takes 47 GB. What could be the reason for that and what could/should I do about it? I do not save any backups in my /ext4.

Hello @james

Thanks a lot for your attention to this issue. My Apps do count 23 GiB in total. So, my WordPress is only 2 GiB. I can tell you, that my WordPress has not been compromised. But, it happened, that I entered "/folder" as backup path in the restore dialogue without the full restore path to WordPress. Then, Cloudron did not restore the WordPress-App alone. It went trough all the apps I have, downloaded them... and kind of installed them somehow. The data is saved in /home/yellowtent/appsdata/APP-ID ... There I find several copies of my general backup:

21.2 GiB [##############################] /snapshot
21.2 GiB [############################# ] /2026-02-13-010000-590
21.2 GiB [############################# ] /2026-02-18-010000-559
21.2 GiB [############################# ] /2026-02-17-010000-635
21.2 GiB [############################# ] /2026-02-16-010000-682
21.2 GiB [############################# ] /2026-02-15-010000-589
21.2 GiB [############################# ] /2026-02-12-010000-697
21.2 GiB [############################# ] /2026-02-14-010000-616
20.9 GiB [############################# ] /2026-02-11-010000-627
20.9 GiB [############################# ] /2026-02-10-010000-615
20.8 GiB [############################# ] /2026-02-09-123024-982
17.0 GiB [######################## ] /2026-02-13-185621-628
17.0 GiB [######################## ] /2026-02-17-230004-017
...
..
.

Is it safe, to delete these files manually?

While using Updraft Plus for WordPress backups, I get this warning message:

Dumping routines: (tq5av_fn_realmedialibrary_childs, wp_fn_realmedialibrary_childs) - (Failed - Your WordPress database user doesn't have sufficient privileges to read these stored routines. To be able to backup the routines, you must be the user named as the routine DEFINER(s), have the SHOW_ROUTINE privilege (for MySQL 8.0.20+ users), have the SELECT privilege at the global level, or have the CREATE ROUTINE, ALTER ROUTINE, or EXECUTE privilege granted at a scope that includes the routines.)

I would like to enter one of these commands to the WordPress CLI (MySQL):

GRANT SELECT on . TO 'wp_database_user'@'localhost';

GRANT SHOW_ROUTINE ON . TO 'wp_database_user'@'localhost';

I get these error messages:

ERROR 1045 (28000): Access denied for user 'wp_database_user'@'%' (using password: YES)

ERROR 1227 (42000): Access denied; you need (at least one of) the GRANT OPTION privilege(s) for this operation

I understand, that I don't have the privileges, but I am logged in as root. What could I do? Is there another way to reach my goal?