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 - Status | Demo | Docs | Install
andreasduerenA

Andreas

@andreasdueren
App Dev
Unfollow Follow
About
Posts
892
Topics
86
Shares
0
Groups
1
Followers
2
Following
0

Posts

Recent Best Controversial

  • Hoarder (Now, Karakeep) - Mymind alternative - The Ultimate All-In-One Bookmark and Note Taking App
    andreasduerenA andreasdueren

    @LoudLemur Thanks, useful pointers. Shipped in 0.1.8:

    Meilisearch version bump: this was the real one. I reproduced it, a 1.40.0 store against the 1.41.0 binary refuses to open. start.sh now compares the store VERSION against the binary, passes --experimental-dumpless-upgrade when the store is older, and archives the store when it is newer, which is what a package rollback produces. Comparison uses sort -V, since string compare gets 1.9.0 against 1.41.0 backwards. Both paths tested on a live box.

    OAUTH_ALLOW_DANGEROUS_EMAIL_ACCOUNT_LINKING now defaults to false and is opt-in from the env file.

    Switched to CLOUDRON_OIDC_DISCOVERY_URL.

    POSTINSTALL now documents that search may be stale after a restore and that Reindex All Bookmarks rebuilds it.

    Web and workers now wait for Meilisearch to accept connections, sixty second bound, then proceed without search.

    Memory raised to 3 GiB.

    Not adopting persistentDirs plus backupCommand. The index here is derivable from SQLite, so the worst case is one admin action, and the snapshot design adds a backup time HTTP dependency plus the clone starts empty behaviour. For your standalone package, where the index is the only copy, your conclusion makes sense.

    Backup abort: not reproduced here either. The package never enables dumps or snapshots and those dirs sit outside the db-path, so they stay empty.

    On cloudron/base: log viewer and web terminal both work on the Debian based upstream image. I used cloudron exec against it throughout,

    App Wishlist

  • How-to: Nextcloud Full Text Search with the Cloudron Elasticsearch community package
    andreasduerenA andreasdueren

    @girish That was the missing piece, thank you. I mistakenly had concluded from the backupCommand docs alone that there was no restore-side hook. restoreCommand is documented, it just isn't cross-linked from backupCommand.

    One thing I hit that may be a bug in 9.2.0: the docs state the backupCommand container shares the app container's network namespace, so services on localhost are reachable. On my install that did not work. curl to 127.0.0.1:9200 failed with exit code 7 (connection refused / could not connect) during backupCommand, on two separate package releases, including one with --retry 30 --retry-delay 2 --retry-connrefused retrying for roughly a minute. The identical command run inside the live app container via cloudron exec succeeded immediately, and the app was healthy throughout.

    I worked around it for now by having backupCommand talk to the live container over a Unix socket in /app/data/run instead of TCP. Happy to provide logs or a minimal reproducer if that's unexpected. restoreCommand shouldn't care since the app isn't running at that point, but backupCommand does depend on it.

    Discuss

  • High Performance Back-end for Nextcloud Files
    andreasduerenA andreasdueren

    @LoudLemur It should be ok. Not what I'm doing currently but the only technical constraint would be CPU bandwidth with too many call participants.

    App Wishlist

  • Virtual Host Style support
    andreasduerenA andreasdueren

    @robi its plentiful but if some people for some reason want it, I think that's the easiest way to implement it. Just like the kutt package does.

    RustFS

  • Virtual Host Style support
    andreasduerenA andreasdueren

    @robi Add as alias to the app I'd say

    RustFS

  • Community store: apps added after today's ssrf fix never appear in the public listing
    andreasduerenA andreasdueren

    Since commit 09c562f (ssrf protection, deployed today), newly added community apps show under My Apps but their public page returns 404 and they are missing from /api/apps.

    Probable cause: in downloadIcon in src/apps.js, secureGet(iconUrl) is now wrapped in safe(() => ...). A superagent request is a thenable, so safe() awaits it and returns a Promise instead of the request object. The next line then calls request.ok(...), which throws TypeError: request.ok is not a function. The error propagates out of resolveEntry, and refreshCache skips the app entirely with Skipping community app <title> (<url>): request.ok is not a function in the log.

    Existing apps are unaffected because their icons are already cached and downloadIcon returns before the broken line. Any app added after the deploy has no cached icon and is dropped from the listing on every refresh.

    Reproduced locally against the current repo with npm ci and a valid versions file (it passes parseVersions and checkVersionsRequirements cleanly).

    Suggested fix: build the request in a plain try/catch instead of safe(), for example

    let request;
    try { request = secureGet(iconUrl); } catch { return; }
    const [error, response] = await safe(request.ok(() => true));
    

    Affected example: Nextcloud Talk HPB, added today. https://ca.cloudron.io/app/nextcloud-talk-hpb returns 404 while the entry exists in My Apps.

    Support community appstore

  • High Performance Back-end for Nextcloud Files
    andreasduerenA andreasdueren

    I've packaged the Nextcloud Talk HPB (nextcloud-spreed-signaling 2.1.1 plus Janus 1.4.1 VideoRoom SFU) for Cloudron and am currently testing it in production with a few Nextcloud instances.

    What it does:

    • Single instance signaling server plus Janus SFU, NATS built in (loopback mode)
    • One install can serve multiple Nextclouds via isolated [backend:<id>] sections
    • Selectable TURN modes: Cloudron TURN addon (default), local coturn, external coturn, Cloudflare Realtime TURN, or disabled
    • Works with both / and the sunweaver style /standalone-signaling/ URL prefix, so migrating from a VPS setup is straightforward
    • Sensible video quality defaults (4 Mbit/s camera, 8 Mbit/s screen share) with a documented knob in config.ini

    The recording backend is currently intentionally not included. May add this in the future.

    TURN choice: i'm personally running the Cloudflare Realtime TURN mode. Cloudron's platform TURN was a bit unreliable for us, and Cloudflare gives you an anycast TURN edge including TURN over TLS on 443 for restrictive networks. Since Talk only speaks coturn shared secrets and Cloudflare issues short lived credentials, the package ships a small credential minting Worker plus a Talk companion app that handles caching and fallback.

    So far my experience with it is slightly better than the sunweaver HPB server. But time and more concurrent users will tell.

    Repo: https://git.due.ren/andreas/nextcloud-hpb-cloudron
    CloudronVersions.json: https://git.due.ren/andreas/nextcloud-hpb-cloudron/-/raw/main/CloudronVersions.json

    Still early. I'd be happy about any feedback, especially from people running other TURN modes or setups with multiple backends.

    App Wishlist

  • Is it possible/safe to install Client Push App ?
    andreasduerenA andreasdueren

    I think I got Nextcloud Client Push (notify_push) working persistently with the current Cloudron Nextcloud package.

    Tested with:

    • Cloudron Nextcloud package 5.8.5
    • Nextcloud 34.0.2
    • notify_push 1.3.5

    This uses only /app/data; it does not modify read-only /app/code or /etc. I verified it across a full Cloudron app restart.

    1. Install Client Push

    Install Client Push from the Nextcloud Apps page, or run this in the Nextcloud app terminal:

    sudo -u www-data php /app/code/occ app:install notify_push || true
    sudo -u www-data php /app/code/occ app:enable notify_push
    

    2. Create the persistent daemon runner

    Run in the Nextcloud app terminal:

    mkdir -p /app/data/notify_push
    
    cat > /app/data/notify_push/runner.sh <<'EOF'
    #!/bin/bash
    
    set -u
    
    binary="/app/data/apps/notify_push/bin/x86_64/notify_push"
    config="/app/data/config/config.php"
    
    if [[ ! -x "${binary}" ]]; then
        echo "notify_push binary is missing: ${binary}" >&2
        exit 1
    fi
    
    # Apache supplies a pipe on stdin. Preserve and drain it so requests cannot block.
    exec 3<&0
    cat <&3 >/dev/null &
    reader_pid=$!
    
    "${binary}" \
        --bind 127.0.0.1 \
        --port 7867 \
        --nextcloud-url http://127.0.0.1 \
        "${config}" &
    push_pid=$!
    
    cleanup() {
        kill -TERM "${push_pid}" "${reader_pid}" 2>/dev/null || true
        wait "${push_pid}" "${reader_pid}" 2>/dev/null || true
    }
    
    trap cleanup EXIT
    trap 'exit 0' HUP INT TERM
    
    wait "${push_pid}"
    EOF
    
    chown www-data:www-data /app/data/notify_push/runner.sh
    chmod 0755 /app/data/notify_push/runner.sh
    

    The daemon binds only to loopback. Port 7867 is not exposed publicly.

    3. Add the internal callback configuration

    The daemon must contact Nextcloud directly instead of looping back through Cloudron’s public proxy:

    cat > /app/data/config/notify_push.config.php <<'EOF'
    <?php
    
    $CONFIG = [
        'trusted_domains' => [
            getenv('CLOUDRON_APP_DOMAIN'),
            '127.0.0.1',
        ],
        'trusted_proxies' => [
            getenv('CLOUDRON_PROXY_IP'),
            '127.0.0.1',
        ],
    ];
    EOF
    
    chown www-data:www-data /app/data/config/notify_push.config.php
    chmod 0640 /app/data/config/notify_push.config.php
    

    Do not add --glob-config to the daemon command. The Rust configuration parser cannot evaluate the getenv() calls in this extra PHP config file.

    4. Add the persistent Apache proxy

    First save the original configuration:

    cp -n /app/data/apache/mpm_prefork.conf \
        /app/data/apache/mpm_prefork.conf.before-notify-push
    

    Then append the integration once:

    if ! grep -Fq "BEGIN CLOUDRON NOTIFY_PUSH" /app/data/apache/mpm_prefork.conf; then
    cat >> /app/data/apache/mpm_prefork.conf <<'EOF'
    
    # BEGIN CLOUDRON NOTIFY_PUSH
    <IfModule !proxy_module>
        LoadModule proxy_module /usr/lib/apache2/modules/mod_proxy.so
    </IfModule>
    <IfModule !proxy_http_module>
        LoadModule proxy_http_module /usr/lib/apache2/modules/mod_proxy_http.so
    </IfModule>
    <IfModule !proxy_wstunnel_module>
        LoadModule proxy_wstunnel_module /usr/lib/apache2/modules/mod_proxy_wstunnel.so
    </IfModule>
    
    ProxyPass "/push/ws" "ws://127.0.0.1:7867/ws"
    ProxyPass "/push/" "http://127.0.0.1:7867/"
    ProxyPassReverse "/push/" "http://127.0.0.1:7867/"
    
    GlobalLog "|/usr/local/bin/gosu www-data:www-data /app/data/notify_push/runner.sh" combined
    # END CLOUDRON NOTIFY_PUSH
    EOF
    fi
    
    chown www-data:www-data /app/data/apache/mpm_prefork.conf
    chmod 0644 /app/data/apache/mpm_prefork.conf
    

    GlobalLog gives Apache ownership of the daemon lifecycle. Apache starts the runner whenever the app starts and respawns it if it exits.

    5. Validate and activate Apache

    apache2ctl configtest
    

    Only continue if it reports Syntax OK:

    supervisorctl restart apache2
    

    Check that the daemon is running:

    ps -ef | grep '[n]otify_push'
    curl -i "https://${CLOUDRON_APP_DOMAIN}/push/test/cookie"
    

    The unauthenticated curl request should return HTTP 400 with Missing request header "token". That is expected and confirms the public proxy reaches the daemon.

    6. Configure Nextcloud

    sudo -u www-data php /app/code/occ \
        notify_push:setup "https://${CLOUDRON_APP_DOMAIN}/push"
    

    All checks should pass:

    ✓ redis is configured
    ✓ push server is receiving redis messages
    ✓ push server can load mount info from database
    ✓ push server can connect to the Nextcloud server
    ✓ push server is a trusted proxy
    ✓ push server is running the same version as the app
      configuration saved
    

    Run the self-test:

    sudo -u www-data php /app/code/occ notify_push:self-test
    

    7. Verify persistence

    Restart Nextcloud from the Cloudron dashboard. Once it is healthy again, reopen the terminal and run:

    sudo -u www-data php /app/code/occ notify_push:self-test
    ps -ef | grep '[n]otify_push'
    

    The saved endpoints should be:

    https://your-nextcloud-domain.example/push
    wss://your-nextcloud-domain.example/push/ws
    

    I also confirmed that both, my Hermes and the official Nextcloud sync client connected and authenticated to the WebSocket after the restart.

    Notes

    This is an instance-level workaround because the current Cloudron package has no custom supervisor hook. It follows the official notify_push architecture: a background daemon plus an Apache reverse proxy.

    Everything persistent is stored in:

    /app/data/apache/mpm_prefork.conf
    /app/data/notify_push/runner.sh
    /app/data/config/notify_push.config.php
    

    The original Apache configuration is retained at:

    /app/data/apache/mpm_prefork.conf.before-notify-push
    

    I would rerun notify_push:self-test after future Nextcloud or Cloudron package updates.

    Nextcloud

  • Mail app: optional SpamAssassin plugins can't be enabled with their stock rules, and `sa-update` never runs
    andreasduerenA andreasdueren

    @girish said:
    Currently, our gitlab is under attack. Almost 40k unique IPs. I took the IPs from our access.log and not some random blocklist.

    oh that explains the downtime it had these days lol

    Support spamassassin

  • How-to: Nextcloud Full Text Search with the Cloudron Elasticsearch community package
    andreasduerenA andreasdueren

    @girish Thanks, didn't know about this feature and implemented what I understood to be best practice in the latest version:

    The package now uses Cloudron’s backupCommand to create an Elasticsearch filesystem snapshot before Cloudron copies /app/data.

    That snapshot is created by Elasticsearch, waits for SUCCESS, and is included in the normal Cloudron app backup under:

    /app/data/snapshots

    So the current situation is:

    Cloudron backup
    ├── normal /app/data filesystem copy
    └── completed Elasticsearch snapshot
    

    If the restored raw Elasticsearch data starts normally, nothing else is required. If it does not, the Elasticsearch snapshot is the supported recovery source.

    I considered stopping Elasticsearch for the entire Cloudron filesystem-copy phase to make the raw copy consistent, but that would add backup downtime and probably be less robust than Elasticsearch’s own snapshot mechanism.

    Discuss

  • Retention Configuration
    andreasduerenA andreasdueren

    @mononym Yes, essentially. A federated room is not stored only on the homeserver where it was created. Each homeserver with participating users receives and stores its own copy of the room events for its local members. The originating server is not a central or authoritative host for the room.

    A newly joining homeserver does not necessarily receive every historical event immediately, but it can request available history from other participating servers, subject to the room's history visibility and federation rules.

    Therefore, Synapse retention is not a remote-delete mechanism. Your default_policy controls only what your own homeserver serves to clients and eventually keeps in its database. If matrix.org, or another participating homeserver, does not enforce equivalent retention, it may retain its own copy of the history. In an encrypted room that copy is ciphertext, but clients that still have the encryption keys may be able to decrypt it.

    A room-level m.room.retention state event is federated and can communicate the intended policy to participating servers, but enforcement still depends on each homeserver supporting and honoring it. It should not be treated as a guarantee that every copy disappears everywhere.

    Small correction to my previous reply: current Synapse versions use a default purge-job configuration when retention is enabled and no explicit purge_jobs section is provided. Adding purge_jobs is useful when you want to control the purge interval, but it is not strictly required.

    Matrix (Synapse/Element)

  • best settings for optimal battery?
    andreasduerenA andreasdueren

    @humpty I'd actually flip your list upside down, because option 2 is a trap: Element's room export is HTML/JSON for reading only. There is no way to import it into a new homeserver. Room history, media, and encryption state can't be rebuilt from it. For someone with lots of journal rooms that path ends in copy-paste hell or data loss.

    Meanwhile your OIDC worry is smaller than you think for the wizard path:

    • The migration copies the whole Synapse database and converts it. Your users log in with passwords today, and password hashes migrate 1:1 (verified in my end-to-end tests). Broken/stale OIDC mappings from the old cross-Cloudron move just become dead links on those accounts; they don't block anything, and the built-in dry-run would flag it if the converter objected.
    • More importantly: rehearsal mode exists exactly for your situation. The old app stays online and completely untouched. The wizard copies everything to a throwaway ESS install, runs the full conversion including a dry-run first, and then verifies the result automatically: user count, devices/sessions, password hashes, signing key. You can't log into the rehearsal copy with a client (it stays deliberately offline, since it carries your real server name on a temporary domain), but the point is that the entire conversion runs end to end on your real data. If your old OIDC weirdness would break anything, this is where it surfaces. Worst case: it fails, you've lost nothing, and you post the error here.

    On a migrated install: the migration writes legacy-passwords.yaml, and render-configs.sh then renders the MAS config with passwords.enabled: true plus two schemes:

    • v1: bcrypt (with the old Synapse pepper if one existed) — so every imported Synapse password hash verifies as-is
    • v2: argon2id — MAS transparently re-hashes to the stronger scheme on next successful login

    So a user with no OIDC link logs in with their old username/password exactly as before; nothing to reset. Users with a Cloudron OIDC link get both options (SSO button and password, if they had one). Your stale OIDC external_ids remain the only wrinkle, they become dead upstream links in MAS, but they can't lock anyone out since password auth stays enabled. The draft reply's claim stands as written.

    So my suggested order:

    1. Copy-paste the truly irreplaceable stuff (cheap insurance, keep that step)
    2. On the fresh Ubuntu: sudo npm install -g cloudron, then cloudron login my.yourdomain.com. That's the whole CLI setup. If pop_os failed it was almost certainly an old node version; Ubuntu 26.04 ships a recent one.
    3. Run the wizard in rehearsal mode (option 1 when it asks). It holds your hand through every step.
    4. Check your rooms on the rehearsal target. If it's all there, do the real thing with a fresh target. If not, nothing was harmed and I'll help debug.

    Nuking should stay exactly where you put it: the rage option of last resort 🙂

    Traccar

  • How-to: Nextcloud Full Text Search with the Cloudron Elasticsearch community package
    andreasduerenA andreasdueren

    This guide configures Nextcloud Full Text Search (FTS) to use Elasticsearch over the Cloudron-internal app network.

    The Elasticsearch REST API is not public. The public app URL exposes only a minimal health endpoint; Nextcloud connects directly to Elasticsearch on internal port 9200.

    1. Install Elasticsearch from the community catalog

    In Cloudron, open:

    App Store → Settings → Community Apps
    

    Add this catalog URL:

    https://git.due.ren/andreas/elasticsearch-cloudron/-/raw/main/CloudronVersions.json
    

    Or install through the Cloudron CLI:

    cloudron install \
      --versions-url https://git.due.ren/andreas/elasticsearch-cloudron/-/raw/main/CloudronVersions.json \
      --location elasticsearch.example.com
    

    Installing from this catalog makes the app community-tracked, allowing Cloudron to discover later package releases through its normal update mechanism.

    Allocate at least 4 GB RAM where possible. The package sizes Elasticsearch's JVM heap from the app memory limit.

    2. Obtain the internal Elasticsearch address and credential

    Open the Elasticsearch app's Web Terminal and run:

    hostname
    cat /app/data/credentials.txt
    

    hostname prints the Cloudron app ID. This is the internal hostname that other Cloudron apps can resolve for the lifetime of this installed app.

    Use the app-ID hostname, not the container IP. Container IP addresses are not a supported configuration value and can change.

    The internal Elasticsearch endpoint is:

    http://<APP_ID_HOSTNAME>:9200
    

    For example:

    http://210f8b84-f417-4697-80b7-efefd18e7329:9200
    

    The generated password is also available at:

    /app/data/secrets/elastic_password
    

    Treat it as a secret. A Cloudron app that has both this password and the internal hostname can query Elasticsearch.

    Important: If the Elasticsearch app is removed and installed again, it receives a new app ID. Update the Nextcloud elastic_host configuration after such a migration.

    3. Enable the Nextcloud FTS apps

    Open the Nextcloud app's Web Terminal and run:

    sudo -u www-data php /app/code/occ app:enable fulltextsearch
    sudo -u www-data php /app/code/occ app:enable fulltextsearch_elasticsearch
    sudo -u www-data php /app/code/occ app:enable files_fulltextsearch
    

    4. Configure Nextcloud

    Set the FTS platform and the index name:

    sudo -u www-data php /app/code/occ config:app:set \
      fulltextsearch app_navigation --value "1"
    
    sudo -u www-data php /app/code/occ config:app:set \
      fulltextsearch search_platform \
      --value "OCA\\FullTextSearch_Elasticsearch\\Platform\\ElasticSearchPlatform"
    
    sudo -u www-data php /app/code/occ config:app:set \
      fulltextsearch_elasticsearch elastic_index --value "nextcloud"
    

    Set the Elasticsearch connection. The password must be URL-encoded if it contains URL-reserved characters such as @, :, /, ?, #, or %.

    sudo -u www-data php /app/code/occ config:app:set \
      fulltextsearch_elasticsearch elastic_host \
      --value "http://elastic:URL_ENCODED_PASSWORD@APP_ID_HOSTNAME:9200"
    

    Replace:

    • URL_ENCODED_PASSWORD with the generated Elasticsearch password, URL-encoded where necessary.
    • APP_ID_HOSTNAME with the value returned by hostname in the Elasticsearch app.

    Example shape:

    http://elastic:REDACTED@210f8b84-f417-4697-80b7-efefd18e7329:9200
    

    5. Test and build the index

    sudo -u www-data php /app/code/occ fulltextsearch:test
    sudo -u www-data php /app/code/occ fulltextsearch:index
    

    The first indexing run can take time, depending on the number and size of files.

    Elasticsearch's built-in german analyzer is available. No separate ICU plugin is required for the standard German analyzer.

    6. Verify Elasticsearch and the public boundary

    Inside the Elasticsearch app:

    curl -u elastic:$(cat /app/data/secrets/elastic_password) \
      http://localhost:9200/_cat/indices?v
    

    You should see the nextcloud index after indexing.

    From outside the Cloudron, verify that Elasticsearch API routes are not public:

    curl -i https://elasticsearch.example.com/_cat/indices
    

    Expected result:

    HTTP 404
    {"status":"not_found"}
    

    The harmless public health endpoint should remain available:

    curl -i https://elasticsearch.example.com/health
    

    Expected result:

    HTTP 200
    {"status":"green","service":"elasticsearch-cloudron"}
    

    Security and operational notes

    • Elasticsearch REST runs on internal port 9200; it is not routed through the public Cloudron reverse proxy.
    • The public Cloudron httpPort serves only /health.
    • The Elasticsearch transport port 9300 has no external Cloudron port mapping.
    • HTTP CORS is disabled by default.
    • Elasticsearch data persists in /app/data; routine package updates do not normally require a re-index.
    • Do not use container IP addresses in Nextcloud configuration.
    Discuss

  • Hoarder (Now, Karakeep) - Mymind alternative - The Ultimate All-In-One Bookmark and Note Taking App
    andreasduerenA andreasdueren

    @necrevistonnezr @loudlemur @jagan @scooke @jdaviescoates @gregy @swheeler78 @ekevu123

    I packaged this for now. But I'm honestly a bit underwhelmed by it.Was hoping it would be more useful as a note taking app, but it's practically only for bookmarks. https://ca.cloudron.io/app/karakeep

    App Wishlist

  • best settings for optimal battery?
    andreasduerenA andreasdueren

    @humpty said:

    @andreasdueren iirc I did compare it to a config of a fresh install and fixed things up but I didn't go into the database end of things.

    I'd be careful messing with the database. Went down that rabbit hole once while I was working on getting the whatsaoo bridge working. What a mess.

    Currently, there's no OIDC working. We can log in via username/email and that works fine.

    Are you saying the Element X app? This is by design and the general limitation of the current package. That's one reason why I worked on ESS, now even QR code login works.

    Honestly, it seems easier to extract the key info from rooms that I want and start fresh with a new matrix/ess app. But, I do have a LOT of rooms as I've been using it as a journal/note-taking app (totally replaced Joplin over time).

    Again, not sure if this is the best solution. Let me know how that went if you do go down that path!

    The OIDC issues happened when I switched from one host to another AND moved the app across Cloudrons that didn't have the exact same users so it messed up the mapping. I think it's seppuku time for the old app 😅

    This sounds like it can be nicely consolidated though. Just delete the users which don't exist anymore.

    Traccar

  • best settings for optimal battery?
    andreasduerenA andreasdueren

    @humpty said:

    I had issues with my matrix server OIDC related stuff

    This may be worth throwing at an LLM. Have you tried troubleshooting your config file with a good model?

    Traccar

  • best settings for optimal battery?
    andreasduerenA andreasdueren

    @humpty

    @humpty said:
    I'm worried it's not going to go well. I'm going to check if I can export rooms and just import them manually into the new ESS.

    Something going wrong is possible. But unless you skip the backup, the worst case is, that your users need to login when you roll back. However, I did one test run with users, rooms and various devices and had no issues.

    Thinking down the line... what would happen to an existing ESS app once Cloudron picks it up and adds it to the official store? Will I have to reinstall and do a restore backup?

    should they decide to support this officially, this would probably be the easiest way to migrate (unless they change something mayor in the package). This would mean

    • shutting down the app
    • taking a backup
    • uninstalling/moving to different domain
    • installing official package
    • importing backup

    Which would only mean downtime for users during the process, but overall a simple and low risk process. The initial migration to the complete package is the tricky part.

    Traccar

  • best settings for optimal battery?
    andreasduerenA andreasdueren

    @humpty Unfortunately we need the CLI because we need to interact with two isolated containers to merge data. Running in either web terminal won't work. Are you running windows? The CLI on macOS has been pretty solid for me.

    Traccar

  • best settings for optimal battery?
    andreasduerenA andreasdueren

    @humpty No problem 🙂

    Traccar

  • best settings for optimal battery?
    andreasduerenA andreasdueren

    @humpty https://www.cloudron.io/store/#app/findmydeviceserver its a bit tedious to set up but if you get it right it works pretty well.

    Traccar
  • Login

  • Don't have an account? Register

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