The QR code tool does not support embedded logos. Mini-qr + code management to later change the destination address would be a dream come true.

We attempted to package this but failed. (First packaging attempt) If somebody else wants to try, this is what we learned: # Lessons from Attempting to Package Pelican Panel for Cloudron ## Key Lessons Learned Here are the top 5 things that caused the most trouble: - **Health Check Stalls**: Pelican's slow startup (e.g., DB migrations, asset compilation) often times out Cloudron's health checks. Extend the Dockerfile's `HEALTHCHECK --start-period` to 120s+ for real use, or use a temporary dummy (e.g., `CMD true`) to bypass for debugging—revert it later to avoid false "healthy" states. - **Env Var Management**: Cloudron rejects an "environment" array in the manifest (validation error: "Unknown property"). Hardcode defaults in Dockerfile `ENV` lines, then manually edit `/app/data/.env` via SSH post-install to inject Cloudron placeholders like `${MYSQL_HOST}` (get them from `cloudron inspect --app <fqdn>`). - **Manifest Validation Issues**: Cloudron is strict—unsupported fields fail installs outright. Stick to the official schema (check [Cloudron docs](https://cloudron.io/documentation/custom-apps/manifest/)), test with JSON validators, and remove extras like custom env sections. - **Git Merge Conflicts**: Editing files locally vs. directly on GitHub leads to push rejections. Always run `git pull origin main` before changes, and resolve conflicts by manually editing/removing markers (e.g., `<<<<<<< HEAD`, `=======`, `>>>>>>>`). - **Image Registry Choices**: GHCR (GitHub Container Registry) can have pull/auth issues in Cloudron; Docker Hub is more reliable for public images. Ensure the manifest's "dockerImage" matches your pushed tag, and verify pulls locally before installing. ## Useful Code Snippets These are anonymized examples that helped during troubleshooting. Adapt them to your setup. ### Basic CloudronManifest.json (Validated, No Invalid Fields) ```json { "id": "dev.pelican.panel", "title": "Pelican Panel", "version": "1.0.0-beta22", "description": "Open-source game server management panel", "tagline": "Manage your game servers with Pelican", "website": "https://pelican.dev", "icon": "logo.png", "healthCheckPath": "/", "httpPort": 80, "manifestVersion": 2, "dockerImage": "yourusername/pelican-panel:latest", "addons": { "localstorage": {}, "mysql": {}, "sendmail": {} }, "postInstallMessage": "After installation, please visit https://${DOMAIN}/installer to complete the setup." } Dockerfile Snippets (Key Sections for Env, Health Check, and Storage) # Default ENV vars (add after FROM php:8.2-fpm-alpine) ENV APP_ENV=production ENV APP_DEBUG=false ENV APP_URL=https://${APP_DOMAIN} ENV APP_KEY=base64:your-generated-key-here # Generate with: docker run -it php:8.2-fpm-alpine php -r "echo 'base64:' . base64_encode(random_bytes(32));" ENV DB_CONNECTION=mysql ENV DB_HOST=127.0.0.1 ENV DB_PORT=3306 ENV DB_DATABASE=pelican ENV DB_USERNAME=root ENV DB_PASSWORD=secret ENV MAIL_DRIVER=sendmail ENV MAIL_FROM_ADDRESS=admin@${APP_DOMAIN} ENV MAIL_FROM_NAME="Pelican Panel" # Production HEALTHCHECK (extend start-period for slow startups) HEALTHCHECK --interval=30s --timeout=10s --start-period=120s --retries=3 \ CMD curl -f http://localhost/ || exit 1 # Dummy HEALTHCHECK (debug only - auto-passes) # HEALTHCHECK --interval=5s --timeout=3s --start-period=10s --retries=3 \ # CMD true || exit 0 # Storage symlinks for Cloudron persistence (add in RUN) RUN ln -s /app/data/.env /var/www/html/.env && \ ln -s /app/data/storage /var/www/html/storage && \ chown -R www-data:www-data /var/www/html /app/data Post-Install SSH Commands for Fixes # SSH to server, then: cloudron logs --app your-app-fqdn # Check high-level logs docker ps | grep pelican # Get container ID docker logs <container-id> # Detailed app logs docker exec -it <container-id> /bin/sh # Enter container # Inside: apk add nano; nano /app/data/.env # Edit env vars # Then: php artisan migrate --force; supervisorctl restart all # Exit and: cloudron restart --app your-app-fqdn Final Notes Testing Tip: Run the image locally (docker run -p 80:80 yourimage) before Cloudron to verify health checks and env vars. Why It's Tricky: Pelican (Laravel-based) needs precise env setup and can be slow to boot—manual SSH tweaks were essential. Sharing: If you build on this, post updates here or on Pelican's GitHub.

@imc67 This aspect is interesting: Error Correction Kopia supports Reed-Solomon error correction algorithm to help prevent your snapshots from being corrupted by faulty hardware, such as bitflips or bitrot.

@marcusquinn Does this solution also archive all outgoing emails from inboxes and apps (like InvoiceNinja)?

@necrevistonnezr Nice find. That is very interesting!

@apesorguk https://forum.cloudron.io/topic/12472/please-use-this-template-to-make-an-app-wishlist-request

I was playing around with Gatus a bit today. While its nice that you can configure all your monitors through yaml, that also makes it a bit more complex to get started since you first need to learn the exact syntax. I guess a config generator tool would be nice. What is is missing compared to uptime kuma is a public status page. You either have to expose your whole dashboard or put it behind auth. My minimal Cloudron app can be found at https://git.9wd.eu/apps/cloudron-gatus. It supports OIDC Login and stores data in the postgres database.

SeaweedFS [image: 68747470733a2f2f696d672e736869656c64732e696f2f62616467652f736c61636b2d707572706c65] [image: 68747470733a2f2f696d672e736869656c64732e696f2f747769747465722f666f6c6c6f772f7365617765656466732e7376673f7374796c653d736f6369616c266c6162656c3d466f6c6c6f77] [image: 68747470733a2f2f696d672e736869656c64732e696f2f6769746875622f616374696f6e732f776f726b666c6f772f7374617475732f7365617765656466732f7365617765656466732f676f2e796d6c] [image: 68747470733a2f2f676f646f632e6f72672f6769746875622e636f6d2f7365617765656466732f7365617765656466732f776565643f7374617475732e737667] [image: 68747470733a2f2f696d672e736869656c64732e696f2f62616467652f646f63732d77696b692d626c75652e737667] [image: 68747470733a2f2f696d672e736869656c64732e696f2f646f636b65722f70756c6c732f63687269736c7573662f7365617765656466733f6d61784167653d34383030] [image: 68747470733a2f2f696d672e736869656c64732e696f2f6d6176656e2d63656e7472616c2f762f636f6d2e6769746875622e63687269736c7573662f7365617765656466732d636c69656e74] [image: 68747470733a2f2f696d672e736869656c64732e696f2f656e64706f696e743f75726c3d68747470733a2f2f61727469666163746875622e696f2f62616467652f7265706f7369746f72792f736561776565646673] [image: seaweedfs.png] Introduction SeaweedFS is a simple and highly scalable distributed file system. There are two objectives: to store billions of files! to serve the files fast! SeaweedFS started as an Object Store to handle small files efficiently. Instead of managing all file metadata in a central master, the central master only manages volumes on volume servers, and these volume servers manage files and their metadata. This relieves concurrency pressure from the central master and spreads file metadata into volume servers, allowing faster file access (O(1), usually just one disk read operation). There is only 40 bytes of disk storage overhead for each file's metadata. It is so simple with O(1) disk reads that you are welcome to challenge the performance with your actual use cases. SeaweedFS started by implementing Facebook's Haystack design paper. Also, SeaweedFS implements erasure coding with ideas from f4: Facebook’s Warm BLOB Storage System, and has a lot of similarities with Facebook’s Tectonic Filesystem On top of the object store, optional Filer can support directories and POSIX attributes. Filer is a separate linearly-scalable stateless server with customizable metadata stores, e.g., MySql, Postgres, Redis, Cassandra, HBase, Mongodb, Elastic Search, LevelDB, RocksDB, Sqlite, MemSql, TiDB, Etcd, CockroachDB, YDB, etc. For any distributed key value stores, the large values can be offloaded to SeaweedFS. With the fast access speed and linearly scalable capacity, SeaweedFS can work as a distributed Key-Large-Value store. SeaweedFS can transparently integrate with the cloud. With hot data on local cluster, and warm data on the cloud with O(1) access time, SeaweedFS can achieve both fast local access time and elastic cloud storage capacity. What's more, the cloud storage access API cost is minimized. Faster and cheaper than direct cloud storage! Back to TOC Features Additional Features Can choose no replication or different replication levels, rack and data center aware. Automatic master servers failover - no single point of failure (SPOF). Automatic Gzip compression depending on file MIME type. Automatic compaction to reclaim disk space after deletion or update. Automatic entry TTL expiration. Any server with some disk space can add to the total storage space. Adding/Removing servers does not cause any data re-balancing unless triggered by admin commands. Optional picture resizing. Support ETag, Accept-Range, Last-Modified, etc. Support in-memory/leveldb/readonly mode tuning for memory/performance balance. Support rebalancing the writable and readonly volumes. Customizable Multiple Storage Tiers: Customizable storage disk types to balance performance and cost. Transparent cloud integration: unlimited capacity via tiered cloud storage for warm data. Erasure Coding for warm storage Rack-Aware 10.4 erasure coding reduces storage cost and increases availability. Back to TOC Filer Features Filer server provides "normal" directories and files via HTTP. File TTL automatically expires file metadata and actual file data. Mount filer reads and writes files directly as a local directory via FUSE. Filer Store Replication enables HA for filer meta data stores. Active-Active Replication enables asynchronous one-way or two-way cross cluster continuous replication. Amazon S3 compatible API accesses files with S3 tooling. Hadoop Compatible File System accesses files from Hadoop/Spark/Flink/etc or even runs HBase. Async Replication To Cloud has extremely fast local access and backups to Amazon S3, Google Cloud Storage, Azure, BackBlaze. WebDAV accesses as a mapped drive on Mac and Windows, or from mobile devices. AES256-GCM Encrypted Storage safely stores the encrypted data. Super Large Files stores large or super large files in tens of TB. Cloud Drive mounts cloud storage to local cluster, cached for fast read and write with asynchronous write back. Gateway to Remote Object Store mirrors bucket operations to remote object storage, in addition to Cloud Drive

I got a response from the upstream team and indeed S3 is not optional but mandatory, the optional is for the original S3 or optionally something like minio.

This looks cool: https://x.com/huly_io/status/1865833101357940937 [image: 1752985521362-7d52a37a-6cda-4961-87e7-8e75ee7b5f3f-image-resized.png] https://docs.huly.io/communication/live-transcription/

@LoudLemur about the broken link I have fixed it in the sample file, and you can fix in <1. minute in your deployed application, if it's still running. go to File Manager open content folder open index.gmi scroll down to the links section remove the "$0" after the '.gmi' on the last 2 links No idea how they got there, copy paste error by me probably. Just to get you up and running with testing

Could be another alternative: https://vrite.io/

@girish Yes unfortunately

To clarify my response, this kind of functionality is definitely useful. I run a self hosted NetBird so different devices can be accessed as if local, across a common 100.121.xxx.xxx range. I just don’t know if deploying FRP in a container app will work to provide access to the host (which I assume is most of the point).

Same comment as for FRP. If an app, does it provide access to the host or just the app ?

@robi This looks like a great project and something worthy of being added to Cloudron. I like how routes can easily be added. Looks like I might have to learn me some Flask:)