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

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.

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.

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

https://github.com/austinvhuang/openmemex

OpenMemex is an open source, local-first knowledge integration platform (aka "second brain" or "knowledge garden") optimized for automation (including caching and indexing of content) as well as enabling neural network machine learning integrations.

This looks like a pretty neat entry in the ever-growing "second brain apps" arena. Some highlights:

• ... OpenMemex is fully functional as a self-hosted application.
• ... SQLite is the central data storage medium
• ... data is organized automatically by timestamp. Topical/conceptual connections can be automatically linked ...
• ... the focus is on automated persistence, retrieval, and (future work) optimizing compression/consumption of information over UI-heavy notetaking tools.

The author is honest about the status "The implementation is currently at functioning pre-alpha MVP maturity", but it may be something worth watching.

I might take a crack at packaging it for Cloudron.

Minio auth configuration seems to be rather awkward. It appears to have pretty decent support for LDAP authentication: https://github.com/minio/minio/blob/master/docs/sts/ldap.md

Do you think it would be a good idea to enable this?

@girish Wow that console UI looks great. Based on the publish date of that article and the current release tag on the console (0.7.0) it seems that it's a pretty new project. As far as being separate I can imagine wanting to have a very lightweight UI for the storage device itself and running the full-featured UI separately, especially if they're targeting k8s-like deployments.

I recently encountered some issues after I switched from wildcard DNS configuration to provider-based automatic DNS configuration.

When you create an app with provider-DNS configured, cloudron will use your provider's API to automatically create the DNS subdomain record to point to your server so cloudron can serve the app. But if you create the app while you have wildcard DNS configured, no specific subdomain will be created. This is expected.

However, if you create the app under wildcard-DNS, then switch to provider-DNS, then the subdomains that would normally have been created when running under provider-DNS are not created automatically when switching between DNS configurations. This can cause a problem when the user deletes their wildcard DNS record because they assume that Cloudron will use provider-DNS to provision DNS entries for all apps.

I propose that Cloudron add a feature to check the DNS entries and reprovision DNS records as required when the user switches DNS configurations. I could imagine this could be implemented by triggering automatically as soon as the user switches DNS configurations, or as a button on the dashboard to recheck that dns entries for all apps are correctly assigned (including my.).

@nebulon Good question, and thanks for the context. It seems they were all created in feb/march this year. Maybe it would have been a good idea to purge the binlogs as part of that release.

After logging in with mysql -uroot -ppassword as described in troubleshooting, PURGE BINARY LOGS didn't do anything and SHOW BINARY LOGS just displayed an error that binlogs were not enabled, so I assume that mysql doesn't recognize them anymore, especially considering their age. So I ran rm binlog.*; I hope that didn't fuck it ¯_ (ツ)_/¯. The space is back now at least.

My backups have been failing recently because of disk space. This wouldn't be surprising (if I use the space I use the space...) except over 50% of the disk space is in the "everything else" category:

I ran some du commands locally and found that mysql is using 22GB by itself, mostly in 100M binlog.NNNNNN files:

root@localhost:/var/lib/mysql# du -sh *
4.0K    auto.cnf
4.0K    binlog.000001
4.0K    binlog.000002
120K    binlog.000003
101M    binlog.000004
101M    binlog.000005
101M    binlog.000006
101M    binlog.000007
101M    binlog.000008
59M     binlog.000009
101M    binlog.000010
101M    binlog.000011
101M    binlog.000012
101M    binlog.000013
101M    binlog.000014
71M     binlog.000015
101M    binlog.000016
101M    binlog.000017
101M    binlog.000018
101M    binlog.000019
101M    binlog.000020
101M    binlog.000021
19M     binlog.000022
101M    binlog.000023
101M    binlog.000024
101M    binlog.000025
101M    binlog.000026
101M    binlog.000027
101M    binlog.000028
19M     binlog.000029
101M    binlog.000030
101M    binlog.000031
101M    binlog.000032
101M    binlog.000033
101M    binlog.000034
101M    binlog.000035
85M     binlog.000036
101M    binlog.000037
101M    binlog.000038
101M    binlog.000039
101M    binlog.000040
101M    binlog.000041
101M    binlog.000042
93M     binlog.000043
101M    binlog.000044
101M    binlog.000045
101M    binlog.000046
101M    binlog.000047
101M    binlog.000048
101M    binlog.000049
88M     binlog.000050
101M    binlog.000051
101M    binlog.000052
101M    binlog.000053
101M    binlog.000054
101M    binlog.000055
101M    binlog.000056
90M     binlog.000057
101M    binlog.000058
101M    binlog.000059
101M    binlog.000060
101M    binlog.000061
101M    binlog.000062
101M    binlog.000063
91M     binlog.000064
101M    binlog.000065
101M    binlog.000066
101M    binlog.000067
101M    binlog.000068
101M    binlog.000069
101M    binlog.000070
68M     binlog.000071
101M    binlog.000072
101M    binlog.000073
101M    binlog.000074
101M    binlog.000075
101M    binlog.000076
101M    binlog.000077
69M     binlog.000078
101M    binlog.000079
101M    binlog.000080
101M    binlog.000081
101M    binlog.000082
101M    binlog.000083
101M    binlog.000084
71M     binlog.000085
101M    binlog.000086
101M    binlog.000087
101M    binlog.000088
101M    binlog.000089
101M    binlog.000090
101M    binlog.000091
70M     binlog.000092
101M    binlog.000093
101M    binlog.000094
45M     binlog.000095
101M    binlog.000096
101M    binlog.000097
101M    binlog.000098
101M    binlog.000099
32M     binlog.000100
101M    binlog.000101
101M    binlog.000102
101M    binlog.000103
101M    binlog.000104
101M    binlog.000105
101M    binlog.000106
101M    binlog.000107
101M    binlog.000108
51M     binlog.000109
101M    binlog.000110
101M    binlog.000111
101M    binlog.000112
101M    binlog.000113
101M    binlog.000114
101M    binlog.000115
101M    binlog.000116
101M    binlog.000117
101M    binlog.000118
101M    binlog.000119
101M    binlog.000120
101M    binlog.000121
101M    binlog.000122
101M    binlog.000123
101M    binlog.000124
101M    binlog.000125
101M    binlog.000126
36M     binlog.000127
101M    binlog.000128
101M    binlog.000129
101M    binlog.000130
101M    binlog.000131
101M    binlog.000132
101M    binlog.000133
101M    binlog.000134
101M    binlog.000135
101M    binlog.000136
48M     binlog.000137
101M    binlog.000138
101M    binlog.000139
101M    binlog.000140
101M    binlog.000141
101M    binlog.000142
101M    binlog.000143
101M    binlog.000144
101M    binlog.000145
101M    binlog.000146
101M    binlog.000147
101M    binlog.000148
101M    binlog.000149
15M     binlog.000150
101M    binlog.000151
101M    binlog.000152
101M    binlog.000153
101M    binlog.000154
101M    binlog.000155
101M    binlog.000156
101M    binlog.000157
101M    binlog.000158
101M    binlog.000159
101M    binlog.000160
101M    binlog.000161
101M    binlog.000162
100M    binlog.000163
101M    binlog.000164
101M    binlog.000165
101M    binlog.000166
101M    binlog.000167
101M    binlog.000168
101M    binlog.000169
101M    binlog.000170
101M    binlog.000171
101M    binlog.000172
101M    binlog.000173
9.7M    binlog.000174
101M    binlog.000175
101M    binlog.000176
101M    binlog.000177
101M    binlog.000178
101M    binlog.000179
101M    binlog.000180
101M    binlog.000181
101M    binlog.000182
101M    binlog.000183
101M    binlog.000184
96M     binlog.000185
101M    binlog.000186
101M    binlog.000187
101M    binlog.000188
101M    binlog.000189
101M    binlog.000190
101M    binlog.000191
101M    binlog.000192
101M    binlog.000193
101M    binlog.000194
101M    binlog.000195
95M     binlog.000196
101M    binlog.000197
101M    binlog.000198
101M    binlog.000199
101M    binlog.000200
101M    binlog.000201
101M    binlog.000202
101M    binlog.000203
101M    binlog.000204
101M    binlog.000205
101M    binlog.000206
101M    binlog.000207
33M     binlog.000208
101M    binlog.000209
101M    binlog.000210
101M    binlog.000211
101M    binlog.000212
101M    binlog.000213
101M    binlog.000214
101M    binlog.000215
101M    binlog.000216
101M    binlog.000217
101M    binlog.000218
28M     binlog.000219
101M    binlog.000220
101M    binlog.000221
101M    binlog.000222
101M    binlog.000223
101M    binlog.000224
101M    binlog.000225
101M    binlog.000226
101M    binlog.000227
80M     binlog.000228
38M     binlog.000229
101M    binlog.000230
101M    binlog.000231
101M    binlog.000232
101M    binlog.000233
101M    binlog.000234
101M    binlog.000235
41M     binlog.000236
101M    binlog.000237
101M    binlog.000238
101M    binlog.000239
101M    binlog.000240
101M    binlog.000241
13M     binlog.000242
4.0K    binlog.index
45M     box
4.0K    ca-key.pem
4.0K    ca.pem
4.0K    client-cert.pem
4.0K    client-key.pem
0       debian-5.7.flag
192K    #ib_16384_0.dblwr
8.2M    #ib_16384_1.dblwr
8.0K    ib_buffer_pool
12M     ibdata1
48M     ib_logfile0
48M     ib_logfile1
12M     ibtmp1
804K    #innodb_temp

It looks like regular maintenance by running PURGE BINARY LOGS BEFORE '<some date>'; is expected. Does cloudron do this today?

This isn't an emergency so no rush (Happy Thanksgiving!). Thanks!

https://github.com/TheAxelander/OpenBudgeteer

OpenBudgeteer is a budgeting app based on the Bucket Budgeting Principle and inspired by YNAB and Buckets. The Core is based on .NET and the MVVM Pattern, the Front End uses Blazor Server.

Already dockerized, should be pretty easy to package for cloudron.

@girish Actually, with a couple improvements, CRON+API could be a wonderfully generalizable app management automation tool.

Three feature requests:

• Cloudron doc page on roles should mention the new App Operator role and describe its permissions
• Add a new environment variable inside each app container, CLOUDRON_APP_ID, which contains the id of the currently running app. This should apply to CRON as well
  • Note: CLOUDRON_API_ORIGIN is already supported
• Add a new CRON-only environment variable CLOUDRON_APP_OPERATOR_TOKEN which is a temporary "App Operator"-role token that is only valid for the current app and for the duration of the cron run.
  • Depending on how the CRON feature is implemented (is this the cron from inside the container or on the host?) this may not work exactly how I'm thinking.

With these features, this idea could be implemented much more generally:

# From this: (user must customize api domain, app id, and token)
curl -X POST https://my.example.com/api/v1/apps/appid/uninstall?access_token=apitoken
# To this: (this is ready to copy/paste for any app in any cloudron, but it stops instead of uninstalls)
curl -X POST $CLOUDRON_API_ORIGIN/api/v1/apps/$CLOUDRON_APP_ID/stop?access_token=$CLOUDRON_APP_OPERATOR_TOKEN

Thoughts?

I was able to help the project get their dockerfile off the ground so that it builds and runs with just docker, but it still has a ways to go. Here are some things I think would need to be improved before it would be suitable for cloudron:

• Reduce image size by copying binary results out of the build stages. This is a bit complex because the project is built with rust/wasm-pack and runs a wasm on the frontend, and uses haskell stack for the backend. I'm not familiar with doing docker optimizations with either of these technologies.
• Change the backend to save all data into a /data volume. This will require some changes in the haskell code.
• Get deps-only build steps working. This would be a nice-to-have for the devs to reduce build times after the first build (which can reach to 40min!), but this one isn't a deal breaker for cloudron. I tried, but it causes some compilation output issues so it was commented out for now.

The author was very nice and quite receptive to changes. If anyone else works on this you may want to just aim at getting them merged upstream.

I'd really like to see this too, but it appears that some work still needs to be done to factor out external dependencies / incidental implementation details from the current code.

This is the self-host umbrella issue, which has had some recent activity: https://github.com/excalidraw/excalidraw/issues/1772

Maybe you could disable the app from the inside with a cron job and then clean it up later at your leisure? I'm not exactly sure how you would stop or otherwise disable the app from within without triggering a restart, but maybe there's something in there.

https://docs.cloudron.io/apps/#cron

@robi @girish yeah that makes sense, use the VPS server for all email, apps on the home Cloudron that need to send outbound can use the same server with the setup described above.

Maybe I'm just being unreasonable, but I'd prefer to have email stored on the home server instead. Partially to shift more compute resources locally (the VPS can be cheaper), and partially for digital sovereignty reasons (e.g. a search warrant would be a knock on my front door, not a silent VM snapshot made by the provider under a gag order).

I guess the right term is "inbound email relay", and the more common reasons to use them are to improve uptime and do pre-filtering for spam. I remember setting this up doing local small business IT before everyone just switched to Office 365...

@girish cool thanks for writing up the details.

How do you manage inbound email? A catch-all would receive it all, but then it still has to be routed to individual users on the home server.

@robi Yes, it looks like outbound would be pretty straightforward to configure -- it's just SMTP. I'm most curious about how inbound forwarding could be achieved, I'm not sure I've ever seen that before, though I don't know why it wouldn't be possible.