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.

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

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.

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

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.

@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.

@robi Yes that's the idea, the docker artifact tool is a mechanism to identify and tag the layers so that the layer that contains the metadata is queryable via the docker registry api.

The main issue is that a "Cloudron App" is both 1. A Docker image, and 2. Metadata that includes CloudronManifest.json, thumbnails, screenshots, etc. For official apps this metadata is hosted in an index on Cloudron.io servers, and for the cli metadata is uploaded from the current directory. If there was a good way to host and retrieve the metadata, one might imagine a "local app store" which the owner could add to their instance by simply entering its docker registry image uri.

Note that this metadata hosting problem is non-trivial. For example, if the Cloudron team allowed third parties to list their own apps on the cloudron store then they would be responsible if the apps contained something bad (regardless of any waivers to disclaim responsibility), so that's a nonstarter. Alternatively, dropping the metadata files in the image would require the server to download the whole image just to list the metadata -- not very practical.

To that end, last year I started developing docker artifact (hosted with Gitea on my cloudron! ) which I believe will be able to treat individual image layers hosted on a docker registry as a generic 'artifact repository' which would allow you to precisely and efficiently download just the docker layers that contain the files you specify (say, CloudronManifest.json and images...). I believe this would make alternative 2 from the previous paragraph practical to implement as long as you take some care when you build your image. Currently it's stalled on technical issues (see issue 10 with my notes), but check out the README for my aspirations for the project.

ERPNext can also do invoicing, if it gets out of testing phase.

@nj I tried installing it to my cloudron and it built successfully, but I ran into an issue with the cloudron cli during installation saying that I need to specify a subdomain (when I clearly did specify a subdomain), then I ran out of time to mess with it until later this week.

frappe framework needs root access to the database

Surely this is not actually necessary to run the app, but is just part of their custom dynamic deployment system (ick). I hope it's possible to extricate the actual app from the framework...

@7dowWilkes That's about it, you can sync back up but that doesn't change the experience. Thank you for testing it out for me!

@7dowWilkes said in GrapheneOS Users: Which is the best midrange phone to have?:

Would you like me to test an app for you? Of course, only the start of the app and the general functions?

I'll take you up on that offer. I've been testing out GitJournal as the mobile side of a cross-platform note taking system -- obviously, synced via gitea hosted on cloudron -- and I'm curious how well it works on GrapheneOS.

I read somewhere that the 4a 5G is better than the 4a due to software support schedule.

From what I've seen looking at the frappe/erpnext system design, it looks like a lot of the service complexity comes from their "bench" system tool that provides multitenancy / "environment duplication" capabilities via their backup and restore system. From my experience being able to branch environments is vital for these kinds of tools, but... that's basically cloudron's core competency. With a bit of work cloudron could probably match any missing features that "bench" has over it.

With bench factored out and its features provided by cloudron directly, I think you'd be left with a single python service that needs redis, mariadb/mysql, and postgresql, which cloudron provides as services already.

Notes:

• "frappe" is the company and also the name of the development/deployment framework for erpnext and other applications developed by the same team
• The frappe/frappe-worker docker image referred to in the frappe_docker/compose.yaml file is built from the source in frappe dir in the frappe/frappe repo
• The bench worker --queue short command (and similar) runs scheduler.py:start_worker()
• The queue workers are a Python RQ-based job scheduling/background task system. RQ uses redis queues

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