I'm gonna try to package it up for Cloudron this evening and report back here with my results.

I started a cloudron app package for Notea, you can find the source here: https://source.infogulch.com/infogulch/notea-app If anyone wants to try it, the docker image for this source is infogulch/notea-app:0.0.1-6.

I did run into some trouble after getting it to start successfully:

• I'm using a minio instance on the same cloudron as the data store for Notea since it doesn't support local file storage directly. This means that it's a bit awkward to configure; after installing the app, open the terminal and edit /app/data/env.sh to add the s3/minio backend storage config, then restart the app.
• I used proxyAuth because I think it's the bees knees but that mostly just caused me extra problems because the notea app implements authentication itself and redirects to /login which obviously doesn't work very well with proxyauth. I did open an issue to request an option to disable the login page.
  • In the meantime, it would probably be more expedient to relent and disable proxyAuth, and use notea's built-in authentication which is just a password configured by setting the PASSWORD env var in env.sh

Notea / https://github.com/QingWei-Li/notea

Self hosted note taking app stored on S3. Notea is a privacy-first, open-source note-taking application. It supports Markdown syntax, sharing, responsive and more.

Brought to my attention by @yusf on Notion-like FOSS app thread.

Just to put my money where my mouth is, here is a formatted view of docker system df -v from one of my cloudrons which shows for each image what its "size", "shared size", and "unique size" is (I hope fits nicely):

REPOSITORY                                    SIZE      SHARED SIZE   UNIQUE SIZE
cloudron/org.navidrome.cloudronapp            2.212GB   2.176GB              36MB
cloudron/im.riot.cloudronapp                  2.223GB   2.176GB              47MB
cloudron/com.github.bitwardenrs               3.286GB   2.176GB            1110MB
cloudron/org.matrix.synapse                   2.555GB   2.176GB             379MB
cloudron/org.jupyter.cloudronapp              3.358GB   2.176GB            1183MB
cloudron/io.gitea.cloudronapp                 2.326GB   2.176GB             150MB
cloudron/github.pages.cloudronapp             2.286GB   2.176GB             109MB
cloudron/net.minecraft.cloudronapp            2.723GB   2.176GB             547MB
cloudron/org.fireflyiii.cloudronapp           3.269GB   2.176GB            1093MB
cloudron/com.docker.registry                  2.284GB   2.176GB             108MB
cloudron/mail                                 2.844GB   2.176GB             668MB
cloudron/sftp                                 2.194GB   2.176GB              18MB
cloudron/io.minio.cloudronapp                 2.236GB   2.176GB              59MB
cloudron/org.freshrss.cloudronapp             2.184GB   2.176GB               8MB
cloudron/postgresql                           2.343GB   2.176GB             167MB
cloudron/net.roundcube.cloudronapp            2.239GB   2.176GB              63MB
infogulch/promnesia-app                       2.224GB   2.176GB              48MB
cloudron/graphite                             2.246GB   2.176GB              70MB
cloudron/turn                                 2.182GB   2.176GB               5MB
cloudron/com.electerious.lychee.cloudronapp   2.248GB   2.176GB              72MB
cloudron/mysql                                2.495GB   2.176GB             318MB
cloudron/redis                                2.182GB   2.176GB               6MB
cloudron/mongodb                              2.299GB   2.176GB             122MB
infogulch/terminusdb-app                      3.331GB   2.176GB            1155MB
cloudron/org.radicale.cloudronapp2            2.187GB   2.176GB              11MB
cloudron/base                                 2.176GB   2.176GB                0B

You might notice that the "size" of every image is at least 2.1GB, but that 2.1 GB is shared between all the apps (namely, cloudron/base) because they all use the same base image. And I don't see any world where I wouldn't pay 2.1 GB to have every one of my images be useably-debuggable in case I needed it.

All this said, there may still be opportunities to reduce image sizes by using multi-stage builds to only copy release files (and not source code) to the final image -- but there's no reason for that final image to not be based on cloudron/base.

Oh cool thanks for pointing that out, I hadn't noticed before.

I guess the downsides don't really apply to me right now, but I'm not sure I'd want to enable arbitrary masquerading if there were a bunch of other people on this cloudron.

I still think it's reasonable for users to be able to send with a subaddress of any of their aliases, without opening the floodgates and allowing them to send from any address at all.

Home Assistant / home-assistant.io

Awaken your home

Open source home automation that puts local control and privacy first. Powered by a worldwide community of tinkerers and DIY enthusiasts. Perfect to run on a Raspberry Pi or a local server.

Pretty awesome application and community. Today I was able to set it up on my Pi3, connected a zigbee usb controller, set up a few light bulbs, and already created scripted automations all within an hour or so. Strikingly straightforward to set up.

I think it would be great if we were able to manage an instance in Cloudron, maybe even on a Pi. I think this would be a great use case for the multi-cloudron feature coming in 7.0.

Home assistant has a Docker-based deployment option; though it also has a bunch of device / hw integrations (zigbee usb controller, for example) which could delay a fully-featured implementation.

@klawitterb Nice thanks for sharing!

it also requires a S3 compatible storage like minio

Maybe this is a good time to bring up the Addon request: blob storage (s3) thread, which proposes a new "s3" addon in the same vein as the database addons that would create and manage s3-compatible buckets for apps automatically upon request in the app definition's manifest.

Some apps, especially recently, store and access data via an s3-compatible api. I think Cloudron should add s3 storage as a new addon that can be requested in CloudronManifest.json to better support packaging such apps.

Some potential apps that would use this addon:

• Outline
• Notea
• Nextcloud

Here are some numbered opinions so you can refer to (refute) them:

1. I think it should be implemented as a Minio server which is set up like the postgresql or mysql addons in that the one instance is configured automatically and can serve a number of different apps. Say, each app that has the s3 addon gets a new random bucket and creds for that bucket.
2. Ideally it can be configured in either local or gateway mode. Users can use local if there is enough storage on their server, or configure a gateway to point to any S3-compatible, Azure, or NAS service. Note that many service providers offer an S3-compatible storage API, so the list of supported providers is already much bigger than just those three, and includes hosts like Backblaze, Linode, DigitalOcean among many others.
3. Figuring out how backups should work will probably be the biggest issue. Here are a few potential solutions:
   a. Just clone / replicate the whole bucket on every backup. Might cost a lot of storage, but that's how backups work today so... See: Bucket Replication Guide
   b. Something-something object versions? Though it might be difficult to, say, take a snapshot of a whole bucket. Bucket Versioning Guide
   c. Minio contributors don't seem very receptive to the general idea of bucket-level shapshots. Taking Backups of MinIO #4398, Snapshots #9376
   d. Just don't support backups at all? (not a fan of this option, but it's technically an option)

Thoughts?

I'm not sure I'd want fancy, distributed filesystems on by default for most apps. I feel like most apps would need custom changes to explicitly support distributed storage, and I'm skeptical that a blanket drop-in distributed-fs solution could meet the performance and reliability needs of the diversity of cloudron users.

I'd rather have multi-node app management than distributed app runtime. Manage all your cloudron nodes and assign apps between them, migrate them etc, but most apps can still only be deployed to one cloudron instance at a time. At least I think this would be a better scaling/ha goal for a v1 implementation.

I suspected some of my apps were consuming a lot of space recently, and I had to do a fair amount of digging before the details became evident. To me this was particularly concerning for backups because they don't do any deduplication and I could end up with many multiples of this increased disk consumption.

It would be nice to have the size of each backup recorded in the metadata for backups. Even if it's a little off compared to my backup host it would still be nice to have an order-of-magnitude estimate.

Alternative to Calendy

Finding meeting times are painful. Meetsy simplifies finding a time that works for you and your friend!

https://www.meetsy.xyz/

https://github.com/robertwt7/meetsy

@timconsidine that's quite concerning! Default-on registration is mentioned in the Kutt docs, maybe it deserves to be highlighted more prominently in the install notes, or the default adjusted.

Registration
Registration is enabled by default. This can be disabled by settings DISALLOW_REGISTRATION=true in /app/data/env

Now that Cloudron adds authentication headers with the proxyAuth addon, maybe the easiest solution to integrate authentication is to use those headers in outline. I guess that might be as simple as adding a new file to the /server/routes/auth/providers dir. This would simplify the cloudron package because it wouldn't have to set up and run keycloak.

https://github.com/outline/outline/tree/main/server/routes/auth/providers

Then the only barrier to packaging for cloudron would be the hypothetical s3/minio addon mentioned above.

This also includes the proxyAuth change that allows Firefly iii to authenticate again, correct?

Neat app. I wonder how it compares to firefly iii

@mehdi iirc, one signal used to detect spam is whether the inbound and outbound IPs are the same. Maybe this is not the case, but Google and Microsoft are pretty finicky about email delivery so my instinct is to keep the externally visible configuration 'clean'. That's why I am looking at a design like this.

Previous discussion on the topic:

https://forum.cloudron.io/topic/6046/proxy-email-via-vps/9

@girish Wow that's great! Thanks for implementing this, I hope that it can be used for other apps in the future.

Did you happen to check whether the x-forwarded-* headers are stripped from the original request? Theres a potential impersonation vuln if we're not careful with these headers in particular.

@mehdi I think we can add Firefly III to the list of apps that use this authentication strategy.

Just to connect things, this is what I was aiming at in the proxyAuth addon thread.

Cloudron uses the ngx_http_auth_request_module to forward auth requests to the /http-auth route, then to 127.0.0.1:3001/auth . See: https://git.cloudron.io/cloudron/box/-/blob/master/src/nginxconfig.ejs#L292

I found this article that describes how to configure nginx and the auth server to provide the user back to the app by using the X-Forwarded-User header: https://redbyte.eu/en/blog/using-the-nginx-auth-request-module/

This is the same strategy used by Firefly III in #5847.

I think we could reenable authentication in firefly iii (and other apps that use this authentication stragegy) with the addition of a few headers returned by the service at :3001 and in the nginx config. I think defaulting to hard-coded X-Forwarded-User would be a good starting place.