Cloudron makes it easy to run web apps like WordPress, Nextcloud, GitLab on your server. Find out more or install now.


Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Bookmarks
  • Search
Skins
  • Light
  • Brite
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Brand Logo

Cloudron Forum

Apps | Demo | Docs | Install
E

ekevu123

@ekevu123
About
Posts
436
Topics
125
Shares
0
Groups
0
Followers
0
Following
0

Posts

Recent Best Controversial

  • Mirotalk - Participants can't see each other 2
    E ekevu123

    It has happened again and I was able to catch a few issues that might be related:

    1. WebRTC: ICE failed, add a STUN server and see about:webrtc for more details
    2. Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://translate.googleapis.com/element/log?format=json&hasfast=true&authuser=0. (Reason: CORS request did not succeed). Status code: (null).
    3. Consumer Transport failed
      Object { id: "9d932828-8aba-4b93-af58-235cb3a06c1b" }

    /home/yellowtent/platformdata/logs/box.log - doesn't contain anything related to mirotalk

    Network logs: lists that umami is failing (probably blocked by plugin) and googletranslate (see above)

    I am sending about:webrtc via e-mail, because it is a huge fail and contains personal information.

    MiroTalk

  • Show Server Time Information in the Cloudron Server Menu
    E ekevu123

    It's in System → Settings, just saying ...

    Feature Requests

  • Self-host Firefox Sync on Cloudron
    E ekevu123

    The original is linked above, the changes are explained (and quite minimal).

    Discuss

  • Self-host Firefox Sync on Cloudron
    E ekevu123

    Are you using Firefox? Did you know you can self-host the sync server on Cloudron? (you know ... because you can). I have just tested this, and it works between Firefox on Ubuntu and Android.

    Here is a tutorial for anyone interested:

    Replication Guide: Adapting Syncstorage-RS for Cloudron

    This guide explains how to take the original mozilla-services/syncstorage-rs repository and adapt it for a single-container deployment on Cloudron with PostgreSQL.

    1. Create the Manifest (CloudronManifest.json)

    Cloudron requires a manifest file to understand the application requirements. Create this file in the root of the repository.

    CloudronManifest.json:

    {
      "manifestVersion": 2,
      "title": "Syncstorage-RS",
      "author": "Mozilla Services",
      "description": "Firefox Sync storage server built with Rust",
      "version": "0.21.1",
      "httpPort": 8000,
      "addons": {
        "postgresql": {
          "version": "14.9"
        }
      },
      "healthCheckPath": "/__heartbeat__"
    }
    

    2. Create the Start Script (cloudron-entrypoint.sh)

    Cloudron provides database credentials through environment variables (CLOUDRON_POSTGRESQL_*). We need a script to bridge these variables into the format expected by Syncstorage-RS.

    cloudron-entrypoint.sh:

    #!/bin/bash
    set -eu
    
    # Default values
    SYNC_HOST="${SYNC_HOST:-0.0.0.0}"
    SYNC_PORT="${SYNC_PORT:-8000}"
    SYNC_MASTER_SECRET="${SYNC_MASTER_SECRET:-}"
    
    # 1. Detect Cloudron PostgreSQL addon
    if [ -z "${CLOUDRON_POSTGRESQL_HOST:-}" ]; then
        echo "Error: PostgreSQL addon not found. Please ensure it is installed." >&2
        exit 1
    fi
    
    # 2. Convert Cloudron vars to Syncstorage connection strings
    # We use the same DB for both storage and token management
    POSTGRES_USER="${CLOUDRON_POSTGRESQL_USERNAME}"
    POSTGRES_PASSWORD="${CLOUDRON_POSTGRESQL_PASSWORD}"
    POSTGRES_HOST="${CLOUDRON_POSTGRESQL_HOST}"
    POSTGRES_PORT="${CLOUDRON_POSTGRESQL_PORT}"
    POSTGRES_DATABASE="${CLOUDRON_POSTGRESQL_DATABASE}"
    
    export SYNC_SYNCSTORAGE__DATABASE_URL="postgres://${POSTGRES_USER}:${POSTGRES_PASSWORD}@${POSTGRES_HOST}:${POSTGRES_PORT}/${POSTGRES_DATABASE}"
    export SYNC_TOKENSERVER__DATABASE_URL="postgres://${POSTGRES_USER}:${POSTGRES_PASSWORD}@${POSTGRES_HOST}:${POSTGRES_PORT}/${POSTGRES_DATABASE}"
    export SYNC_TOKENSERVER__RUN_MIGRATIONS="true"
    
    # 3. Validate required config
    if [ -z "$SYNC_MASTER_SECRET" ]; then
        echo "Error: SYNC_MASTER_SECRET must be set in the Cloudron Environment tab." >&2
        exit 1
    fi
    
    # 4. Start the application
    exec /app/bin/syncserver "$@"
    

    3. Adapt the Dockerfile (Dockerfile.cloudron)

    The original Dockerfile often uses modern features like Docker BuildKit (e.g., --mount=type=cache or --chmod in COPY) which might not be supported in all environments. We created a "clean" version that works with standard Docker.

    Key Changes Made:

    1. Set Defaults: Set SYNCSTORAGE_DATABASE_BACKEND and TOKENSERVER_DATABASE_BACKEND to postgres at the top of the file.
    2. Remove BuildKit mounts: Removed all instances of --mount=type=cache... from RUN commands to allow building without BuildKit enabled.
    3. Remove inline chmod: Changed COPY --chmod=0755 to standard COPY followed by a RUN chmod +x command.
    4. Inject Start Script: Added the cloudron-entrypoint.sh and set it as the ENTRYPOINT.

    Fragment of changes in the final stage:

    # ... after all builds ...
    COPY --from=builder /app/bin /app/bin
    COPY cloudron-entrypoint.sh /app/cloudron-entrypoint.sh
    
    # BuildKit-compatible chmod replacement
    RUN chmod +x /app/cloudron-entrypoint.sh
    
    USER app:app
    ENTRYPOINT ["/app/cloudron-entrypoint.sh"]
    

    4. Building and Pushing

    To build the image using the new Dockerfile and push it to Cloudron:

    # 1. Build locally
    docker build -f Dockerfile.cloudron -t syncstorage-rs:cloudron .
    
    # 2. Push to Cloudron Registry
    docker tag syncstorage-rs:cloudron CLOUDRON_IP:5000/syncstorage-rs:cloudron
    docker push CLOUDRON_IP:5000/syncstorage-rs:cloudron
    

    5. Summary of logic

    1. Single Container: We package the Rust binary and its Python dependencies into one image.
    2. PostgreSQL Integration: Instead of separate containers for Sync and Token databases, we point both services to the single PostgreSQL database provided by Cloudron.
    3. Auto-Migrations: We set SYNC_TOKENSERVER__RUN_MIGRATIONS="true" so the database schema is created automatically on the first start.
    4. Security: The SYNC_MASTER_SECRET is the only manual configuration required, ensuring data is encrypted at rest.
    Discuss

  • Per-app breakdown of server resource usage
    E ekevu123

    Well, there are 44 services, so I don't really want to select and de-select them in varying configurations.

    I would add an app list somewhere, that's the suggestion I have made above.

    Feature Requests

  • Per-app breakdown of server resource usage
    E ekevu123

    The bug is fixed now! But I still don't get the per-app overview. When I choose all apps and services, I still see the tops only.

    So, doable, sure, but maybe someone else wants this feature as well, so we can leave this open.

    Feature Requests

  • Per-app breakdown of server resource usage
    E ekevu123

    Right, I didn't use this yet because of the bad user experience (sorry!).
    In particular:

    • When I select/unselect apps, I need to update the timeframe for the changes to have effect. This is a bug, it should update immediately.
    • Most importantly, though, I wouldn't put this on hover, the list is long in my case and the numbers are very hard to read. The list is unsorted as well.

    I guess the feature request would be to make this a separate section with basic table functions (filtering, sorting, searching). This would be a great UI win.

    Feature Requests

  • Staging environment for custom apps
    E ekevu123

    @timconsidine said in Staging environment for custom apps:

    @ekevu123 I think we have a different understanding of staging.
    No point in testing an app before promotion without real data.

    Sure. I assumed you wanted to say that you install a second app, and then swap domains between the original and second app, which would mean that the second app without the data becomes production.

    Maybe I misunderstood?

    Feature Requests

  • Per-app breakdown of server resource usage
    E ekevu123

    Yes, getting a quick overview of all apps for comparison. I don't see any specific apps in the system-wide stats/graphs, maybe because there's no outlier.

    Precisely, I'd like to see whether there's an app using too many ressources, RAM in my case, without accessing every single one of each. I wouldn't need to know only the top apps, because that might be justified.

    Feature Requests

  • Staging environment for custom apps
    E ekevu123

    @timconsidine If you use the cloudron database add-on, the data wouldn't be transferred this way.

    @nebulon said in Staging environment for custom apps:

    I am not 100% sure what the proposed solution here is, but sounds like a simple shell script wrapper around the cloudron cli achieves that already?

    Essentially this would be:

    1. backup prod app
    2. clone from prod backup to staging
    3. update stating app instance
    4. test
    5. if test is good, update the prod app

    Is there anything missing from this?

    I can't say for sure, I kind of wanted to start a discussion first and see if other users have the same problem.

    Feature Requests

  • Per-app breakdown of server resource usage
    E ekevu123

    I have just realised there's no per-app breakdown of server ressource usage in the UI, unless one app is big enough to appear in the overall statistics.

    But I think it could be helpful to understand quickly which app uses how much space, which app uses the most RAM etc.

    Feature Requests

  • Staging environment for custom apps
    E ekevu123

    @scooke said in Staging environment for custom apps:

    Naaah. If you want to use custom apps there are lots of options built just for that for you to have fun with (easypanel, runtipi, yunohost, etc.). Cloudron is for Cloudron-prepped apps; they admire the tinkerer mindset and graciously leave it open for those who can tinker to do so. I don't think they need to formalize/code-alize this option any more than they have.

    I just noticed there isn't a downvote option.

    For me, the purpose of cloudron is to let me run popular open-source apps next to my own ones without the need of an additional server. If that's a minority opinion around here, I gladly retract my suggestion, but I don't think just saying "I wouldn't benefit from this feature" is a reason for not letting others have it.

    @humptydumpty said in Staging environment for custom apps:

    The whole switching thing sounds unnecessary. Why not have a "sync" button to keep the staging site up-to-date with the production site for future testing?

    I am with you here. Let's see it more as an open discussion how staging vs. production could be simplified (if needed).

    Feature Requests

  • Staging environment for custom apps
    E ekevu123

    Yes, but that doesn't matter much, there could be some UI and CLI shortcuts implemented around it.

    Feature Requests

  • Staging environment for custom apps
    E ekevu123

    When I want to update a custom app but make sure there's no deployment-related issue, I have too choices on Cloudron:

    • Update my app, hope for the best and revert immediately using backup (easy, but causes 1-2 minutes of downtime)
    • Create a second app for staging only, test it there, and if needed, push again to production

    Suggestion: Introduce a staging environment for custom apps

    1. Under the hood, this is another custom app in cloudron, but the UI treats it differently
    2. I install it using cloudron update --staging for my app
    3. I can reach it under a staging domain
    4. If I am happy, I can push a button (or run Cloudron CLI) to direct traffic to the new app instead of the previous one. Ideally, staging becomes production and old production gets deleted to reduce downtime, but I haven't thought this through.

    Benefits of this approach over the current one:

    1. I don't have to create two apps for the same thing, because logically, this is one app in different states
    2. Hopefully, this approach could reduce downtime
    Feature Requests

  • Can Syncthing tell me when it fails?
    E ekevu123

    Syncthing is usually great, pretty much set up and forget.

    However, one folder stopped syncing three weeks ago. Apparently, because there was not enough space on the disk and even if that was temporarily the case, it isn't an issue anymore. Unfortunately, it didn't seem to have retried since then.

    That's why I am wondering, can Syncthing tell me somehow when syncing fails?

    Syncthing

  • Store DNS provider keys
    E ekevu123

    Not sure if cloning is exactly UI-friendly here. The user intention is to add another domain, which is a separate action than cloning. You'd assume you perform an action that is separate from other domains, I'd say.

    For backup sites, I am more with you: There it makes more sense to use the same site, but change a detail.

    Feature Requests domains

  • Bug report: error message not clear
    E ekevu123

    Yes, this is with Porkbun DNS and it happens when I change a location of an app. It would be great if it could show the domain, so that I know where to look, and perhaps it would also be helpful if the domain tab marked that domain, as "invalid API key" is a permanent error anyway.

    Support location

  • Store DNS provider keys
    E ekevu123

    I host most of my domains in one Porkbun account, but this would work similarly for any other provider. For any new domain I add, I need to find again the API key and secret key and add it. If they ever change, I need to change them for all domains separately.

    Idea: Store the secrets separately, and allow the user to change/update them in one place. This would be optional, and the user could still use separate API keys per domain, but I think we can assume that one would want to use the same pair of keys for the same account in Cloudron.

    Besides, the values are stored already anyway if they are in use, so this changes only the underlying database structure and the UI.

    Feature Requests domains

  • Bug report: error message not clear
    E ekevu123

    Following up on this, if it errors out, then maybe the domain menu could show a warning. This is at least where I would expect it.

    Support location

  • Old system backups are not listed
    E ekevu123

    @girish You wanted to know when this happens again somewhere

    Support update backup
  • Login

  • Don't have an account? Register

  • Login or register to search.
  • First post
    Last post
0
  • Categories
  • Recent
  • Tags
  • Popular
  • Bookmarks
  • Search