@nj slightly off-topic but any suggestions of a tutorial for implementing Authentik ?
The documentation is totally clear but lacking in 'how to'.
The only I found (https://xpufx.com/posts/protecting-your-first-app-with-authentik/) was helpful as regards authentik but basically said it's all down to network config and provided little guidance as to what network config.
Is anyone else using this outside Cloudron already?
I tried this on CapRover but couldn't get it working.
Maybe bad packaging there.
I will try to give it another go.
@Aizat my sympathies - I got caught by this also on some (non-Cloudron) backups.
Just wanted to say, in case you can't get your question resolved, I use Scaleway for my Cloudron backups, as they don't have this 90d restriction.
And I found a Hetzner Storage Box provides a not-too-disimilar cost compared to Wasabi, bearing in mind the flexibility it provides and no minimum storage durations.
@girish sorry to say it's SSDNODES : it's a scratch VPS for testing.
@girish FYI I'm still getting the same error on a pure fresh install of Ubuntu - definitely 20.04
Script says installing 7.2.1
Tried 3 times
Setting up collectd (5.9.2.g-1ubuntu5) ...
Job for collectd.service failed because the control process exited with error code.
See "systemctl status collectd.service" and "journalctl -xe" for details.
invoke-rc.d: initscript collectd, action "restart" failed.
● collectd.service - Statistics collection and monitoring daemon
Loaded: loaded (/lib/systemd/system/collectd.service; enabled; vendor preset: enabled)
Active: activating (auto-restart) (Result: exit-code) since Wed 2022-05-25 20:31:09 UTC; 11ms ago
Docs: man:collectd(1)
man:collectd.conf(5)
https://collectd.org
Process: 86007 ExecStartPre=/usr/sbin/collectd -t (code=exited, status=0/SUCCESS)
Process: 86008 ExecStart=/usr/sbin/collectd (code=exited, status=1/FAILURE)
Main PID: 86008 (code=exited, status=1/FAILURE)
dpkg: error processing package collectd (--configure):
installed collectd package post-installation script subprocess returned error exit status 1
Processing triggers for systemd (245.4-4ubuntu3.17) ...
Processing triggers for man-db (2.9.1-1) ...
Processing triggers for libc-bin (2.31-0ubuntu9.9) ...
Errors were encountered while processing:
collectd
E: Sub-process /usr/bin/dpkg returned an error code (1)
@robi I just noticed this while exploring
Any thoughts on impact / future ?
@Sam_uk / @marcusquinn : did the packaging for authentik get anywhere ?
@nj said in Authentik - Making authentication simple.:
If I had to choose between Authentik and Keycloak I'd pick Keycloak any day
I'd love to know more about why this opinion.
Keycloak sure looks an impressive beast.
But it seems to me almost "too impressive".
My brief review suggests to me that it is an Enterprise solution.
And it's only suitable for apps supporting OpenConnectID.
Great if they do, but that's a limited selection in reality.
Which is not what is needed "any day".
I'm not knocking Keycloak. Maybe I will come to love it.
For now I just want to put an authentication front-end in front of some simple utility apps which have no auth.
Seems that's not what Keycloak is about.
@nj awesome ! thank you !
I just installed it as a custom app. Looks great. BUT ...
I haven't a scoobies how to use it !
There's far too many words on their website, and far too many options in the app.
2 questions :
@BrutalBirdie good tips born from experience !
@humptydumpty good suggestions !
@micmc I agree, as I've commented somewhere above.
The packaging documentation is good, but doesn't particularly help new packagers on their journey.
We need more examples, walkthroughs, even boilerplates.
I understand that's quite a burden for busy staff.
I'm going to knock up a wiki, but welcome contributions.
Especially with the right answers !
To kick it off :
https://forum.cloudron.io/topic/7087/packaging-own-apps-what-guidance-do-you-want
Picking up on comments in other threads, I'm thinking to start a wiki that can provide some entry-level guidance.
This will not (must not) replace official packaging documents.
Rather it can be an entry to the official docs for those who read them and don't know how to start, plus tips examples etc.
So I'm curious :
@robi I kinda agree, which is why I asked whether a dashboard app like Flame or Heimdal would work. But the response suggested that the requirement was specifically for dozens of tiles/apps in the app dashboard.
Maybe the admin's dashboard would be full but individual users would only see a subset making it more viable for them.
I don't know enough about the 'use case' and just knocked the shortcut-app as a proof of concept.
I'm actually using it myself as a 1-click access to a Flame instance running on another VPS, so my Cloudron Dashboard can provide quick access to non-Cloudron apps.
@robi total newbie to sysbox here.
Is it a case of run sysbox on Ubuntu, then run Cloudron in one sysbox container and <a.n.other.docker.app> in another sysbox container ?
@girish as I understand the thread's initial post suggestion, it is not about external apps hosted elsewhere and accessible from Cloudron dashboard.
It's about having an additional "environment" where users can more easily deploy their apps without them being in the Cloudron App Store and meeting the requirements for that.
That sounds to me like having a Portainer-like capability as a top-level app, or a Caprover-like ability to facilitate deployment of apps which are bog-standard docker run xxx or docker-compose.
As regards the latter, I've looked at self-deploying in Caprover and Dokku (self-hosted Heroku), and it's far from as simple as it seems.
Maybe it's a comfort thing but I prefer the Cloudron self-build/self-deploy approach.
So please nobody take these comments as supportive of a Caprover/Dokku facility in Cloudron.
I think it's a swamp which will suck precious resource.
A Portainer-like facility seems to me more stable and robust.
Maybe it's a question of being able to have Cloudron and Portainer running on the same (big) VPS without them affecting each other.
I'm not technical to know if that's viable.
But I think that is what is being asked for, or a way of delivering what is being asked for.
I should probably shut up now 
@Matus thank you
Cloudron does use Docker, but not docker-compose.
Let me take a look, scratch my head a bit and do some tests. Then I will shout when I can't fix something.
@Matus very good to have you here (sorry for late reply).
I am tempted to have a bash at packaging this for Cloudron.
But I'm sure I will need to shout for help.
Might take me some time so don't set any expectations !
@marcusquinn I totally get the sentiment behind the topic headline.
Personally I am torn :
On balance (although it's a fine 60:40 balance) I tend to support keeping Cloudron's platform boundaries strict.
But how then to address the natural desire of passionate users to do more?
That's the conundrum.
Also the maintenance burden becomes bigger quite quickly.
I have approx 100 deployed apps on my Cloudron and about 10 each on a Docker VPS and a Caprover VPS.
The ratio of my maintenance time is of the order of 10:50:40 (Cloudron:MyDocker:MyCapRover).
That is ridiculous really when the apps are 100:10:10.
There is a big warning there!
A side consideration of supporting docker run xxx and docker-compose up -d type of apps is something like Portainer quickly becomes essential.
I think I might spin up a 2-app throwaway Cloudron and experiment with LXD/LXC for docker run and docker-compose up. But other more competent people will have more valid opinions on the wisdom of this.
Hope that's not a useless ramble.
In the app setting, the Documentation dropdown has an entry for Documentation, but it goes nowhere.
Bad link ?
@jdaviescoates said in Shortcut App:
I'm pretty sure I've seen @girish say this is coming soon, I guess in 7.3
And I am sure they will do a much better job than my hack.
But as we're not yet fully at 7.2, maybe it can be an interim solution if someone is feeling pain on this issue.
@marcusquinn I am not sure I understand the requirement fully, but I have knocked up a simple app.
https://git.cloudron.io/timconsidine/shortcut-app
When installed, it shows a "Tile" on the Cloudron My Apps.
When clicked, it goes to a URL which is specified in /app/data/.env which you can edit using the app's File Manager or Terminal.
As a custom app, no backups and no prompts to update it.
There's nothing much special about this.
I just hacked the Cloudron tutorial-node-js app.
If you clone the repo, there is a build script cld.sh.
Assumes you have Docker and Coudron CLI installed.
If I have misunderstood the requirement, do say.
EDIT : restart the app after changing the .env file.
EDIT (2) : if you have dozens of these single-click-shortcuts, you will probably want to replace the icon after install for visual differentiation to avoid a sea of identical icons, and change the Display name. Manual process but a one-time task for each. Other than that, it should be "set and forget".
@marcusquinn hmmm
working on a PoC (proof of concept) ....
@marcusquinn : ah ok
Not sure how to do it without a redirect.
@marcusquinn : are you meaning something like Flame (https://github.com/pawelmalak/flame) or Heimdahl (https://github.com/linuxserver/Heimdall) ... or something simpler ?
@girish yes, seems to be entirely self-hosted.
There is no landing page or app front page.
You get an error if you try to access the URL.
It just needs to be running, and then typically in the settings of a browser extension (under Advanced) you can specify your custom url (in form of https://app.domain.tld/v2)
LanguageTool is one of the built-in "services", as they call their packaged apps. Terminology a little strange, but hey ho.
So really it is just a question of :
That's all that's needed from memory.
I can reinstall the service if you need 
% certainty of steps.
Coolify is interesting, but quite sparse in terms of apps.
Not a patch on Cloudron.
Seems more angled to deploying own written apps.
Links to Github nicely to pull repo, but I can't get my Cloudron Gitlab linked.
@plusone-nick nice list !
I tried Saltcorn and while it is attractive in many ways, I would not recommend it as it is easy to 'hack' the url to view data of another user/client/transaction that should not be available.
Unless they have fixed this in terms of url exposure.
@ruihildt indeed very cool
Just deployed languagetool on a Coolify instance, and it's very nice.
Dockerfile doesn't seem too complex, but some pieces I am not sure how to handle for custom package.
@girish yay ! 
Despite the hour I couldn't resist trying it.
I changed the location of the api from minio-api.domain.tld to minioapi.domain.tld (just removed the hyphen) and saved the change.
Renewed certs and logs now show the api domain in there.
Tested with Minio mc CLI and Forklift : they both list buckets and contents.
Will check MountainDuck and others later.
Thanks for your patience and support.
Marking it solved !
@girish yep, seems to be a cert issue
The cert for minio.domain.tld is shown in the logs, but there is no entry in the logs for minio-api.domain.tld.
I'm using wildcard DNS (cloudns.net).
The DNS entries are fine for domain.tld (I have a number of apps on the domain).
I will try to force it by changing the Location in the morning.
If necessary, I will download the data content and recreate the app.
I think we're close to a solution.
Will confirm in the morning.
I've began looking into Cloudron alternatives like YunoHost
I tried Yunohost a while back and found it flakey.
Caprover is better than Yunohost, but that also has a fair number of apps that don't install correctly.
Neither of them are a patch on Cloudron, which is rock-solid. Having spent many hours on alternatives, I would strongly recommend spending less total time on making Cloudron work for you.
As @girish says, FreshRSS and TinyRSS work well.
I don't know the advantages of Miniflux, but maybe it could be packaged.
I would like to have database access which can be quite limited in Cloudron
A little surprised by this. I was of the opinion database access in Cloudron is good. What functionality are you wanting that you don't feel is available?
@girish I've tried various approaches based on using minio-api.domain.tld and the standard 443 port :
None of them connect properly.
I haven't tried Expandrive but don't expect any different.
Even the "official" Minio mc CLI app (https://docs.min.io/docs/minio-client-complete-guide.html) fails with this message.
$ mc ls minio
mc: <ERROR> Unable to list folder. Get "https://minio-api.domain.tld/": x509: certificate
is not valid for any names, but wanted to match minio-api.domain.tld
I'm no expert but I'm starting to think there is an issue with Cloudron's minio implementation. Maybe simply that the certificate for the installed app is valid for the console url, e.g. minio.domain.tld but not for minio-api.domain.tld
I'm not sure how to properly test the certificate for minio-api.domain.tld, but a clumsy attempt to visit https://minio-api.domain.tld (without expecting it to render a page) gives the standard certificate problem response :
Your connection is not private
Attackers might be trying to steal your information from minio-api.domain.tld (for example, passwords, messages, or credit cards). Learn more
NET::ERR_CERT_COMMON_NAME_INVALID
This server could not prove that it is minio-api.domain.tld; its security certificate does not specify Subject Alternative Names. This may be caused by a misconfiguration or an attacker intercepting your connection.
Is it dumb to question whether minio-api.domain.tld can actually be verified by connecting apps ?
Why else would Minio's mc app fail to connect ?
@girish I was guessing about 9000 / 9001 based on some internet references. Thanks for clarification.
Getting a connection but still unable to list bucket contents.
Close to giving up on Minio.
Used to work for me in Forklift.
That no longer works, I'm guessing for same reasons that MountainDuck is struggling.
well it seems that I can get a connection using the minio-api.domain.tld and 443
Doesn't compute given earlier messages.
But I then get listing directory xxxxx failed org.xml.sax saxnotsupportedexception
So maybe this is a MountainDuck issue, which of course is not a Cloudron issue.
Trying minio-api.domain.tld in the browser (for debug purposes) generates a certificate not trusted error.
Certificate problem ??
Or more likely E30 (error 30cm away from keyboard)
I'm trying to access my minio app using Mountain Duck to mount it as a drive on local machine (MacBook).
Using recommended profile : S3 HTTPS
Have :
Trying with port 443 says I must use API port for S3 requests.
OK, so trying with 9000 and 9001 I get a timeout.
Tried on minio.domain.tld and also minio-api.domain.tld
Dumb question : what port should I be trying ?
@micmc : it seems no setup fee in UK according to their website, some launch promo I guess.
I get the issue about needing a VPS for short-term use.
I use a monthly fee VPS which is regularly wiped and re-purposed. So not sure monthly pricing is a huge issue but yes, it does tie hands a little.
@BrutalBirdie that's fine.
Yes, I'm using Cloudron user management and restricting access with that.
I don't need per-user repos.
If I did, I would probably set up a separate instance of the app and restrict it by user.
Cool, thank you. Now I will de-docker-hub myself !
@BrutalBirdie thank you! Nice and easy solution. I like those
Follow-up : I also don't see a way to set a repo to be private.
Is it correct understanding that it's automatically private because it's in my private registry ?
i.e. someone would need to log in to the registry to see images and download them
Nervous to ask because probably revealing my stupidity.
I have been using Docker Hub as my docker repository but it is has limit on private repositories.
So I am trying the Docker Registry app from Cloudron App Store.
Installed.
Pushed a test build to it.
Can see it listed in the app interface.
But I cannot see an option to delete it in the UI.
Is there one ? Do I need use the CLI to remove it ?
@girish the way I read it is that the self-host can test against different remote servers to get a truer indication of connection speed across multiple remote endpoints
--server SERVER Specify a SERVER ID to test against. Can be supplied
multiple times.
although that's from the cli implementation
@msbt and @girish : I built this today from https://git.cloudron.io/msbt/opencart-app
I had to :
Other than, it installed fine ! Thank you @msbt
Given the relative lack of ecommerce apps in the App Store, I would highly recommend this receives an official check and addition to the AppStore.
OpenCart may not be the best or most modern app, but it would sure be good to have at least one option available in the App Store.
I don't know how to fork/merge/pull request, but I could create an updated repo if that helps.
Or I could learn how to fork/merge/pull request !! (But that might take some time.)
@infogulch yes ! Surprised me.
I normally check when installing an app.
But seems I did not on this.
Would certainly recommend all other users of Kutt to check env in /app/data/ to disallow registrations.
Going to open a github issue to set this to disabled as a default.
Kinda ridiculous that I have to do a postgres terminal query to check users.
If they support users, they should support some admin function to view users, delete, block etc etc.
OK I checked postgres user table.
3 dodgy entries in there.
So user sign up was active not disabled as I thought.
Now deleted.
I just noticed my Kutt supports account signup from the login page.
I did not think this was in operation.
And the system does not give any option to show users who may have signed up. Bizarre.
How can I check other users ?
I have a Kutt implementation.
Actually it only had ONE link in use.
Tonight I received a take-down notice because a malicious link had been inserted into the system's database.
Along with 4 others.
I have :
But how did they get the 5 bad links into the database??
I tried to check the access.log for apache and nginx.
But they are zero-length. Is logging not automatic ?
Questions :
@ultraviolet looks nice.
Is your repo ready for sharing ? No worries if not.
Seems like it could be deployed in a LAMP app w/o a repo ?
But I haven't tried that.
@nebulon 
no rush, no problem
Just updated my Cloudron CLI install and saw this :
$ npm install -g cloudron@4.15.3
added 2 packages, removed 1 package, changed 115 packages, and audited 118 packages in 6s
1 high severity vulnerability
Does it matter ? Is it really a high severity vulnerability ?
@robi : after some fiddling, I have self-packaged Raneto for Cloudron
https://git.cloudron.io/timconsidine/raneto-for-cloudron
Biggest challenge was adapting to the Cloudron separation of /app/code and /app/data. The app author seemed to envisage a single directory structure for app and content/config. Not technically difficult, just fiddly to work out where things were hiding.
As ever, I may not have done it the best way, so happy to receive advice on improvements.
NB : I have added a postinstallMessage about the default login credentials. They need to be changed in /app/data/config.js. Other config changes possible there too. The message shows in the app settings Documentation drop-down, but it doesn't pop up on first run, like the App Store apps. Haven't found out how to do that.
Background : I have Raneto running nicely on a small CapRover deployment, but I was 'itch-scratching' as I want it on my primary VPS which is Cloudron.
No idea whether it is suitable for the AppStore or what improvements needed for that. But if the self-package helps someone to scratch their own itch, yay!
EDIT : Raneto can probably be installed in a Cloudron LAMP app, if that's easier for people than doing a self-install.
@LoudLemur maybe install eleutheria custom app from @atridad ?
and make a link as @jdaviescoates suggests
Having said I can't find the eleutheria package again at the moment.
@girish I have a separate "MyDocker" VPS for testing/playing and for 'live' apps which are not yet/never going to make it into Cloudron. I like this because I like to keep my Cloudron VPS pure.
It's not a good answer to your question, but I suspect many will answer they want to avoid the cost of a 2nd VPS. But I should not put words in mouths.
If the Cloudron experience would be at risk from 'unmanaged' docker deployments, I gladly accept the cost of a 2nd VPS and accept keeping Cloudron pure.
@Aizat ok, thank you, that's good motivation !
@Aizat apologies for not doing my own research, but just wondering whether this offers more than NocoDB or Baserow which are already here in Cloudron AppStore ?
@girish added LICENCE
I thought best to copy over the licences from the original author repo.
Wouldn't want to say anything different and offend them.
If that's not best approach, do say.
@murgero : I tried VSCode a bit more, and tried Sourcetree.
GitHub Desktop didn't gel for me (don't really know why).
Update for anyone else sitting on the fence : try VSCode !
Works really nicely, easy integrated environment, relatively low learning curve.
Certainly suits me as a relative beginner.
ok my self-package is working now
https://git.cloudron.io/timconsidine/changedetection-for-cloudron
I had problems with their Dockerfile, so I made my own using their python install approach.
@staff may recommend this is not good, and very happy to receive advice on that.
However it's working.
Just a simple app which could be installed perhaps in a LAMP container.
Having it as a (self-)package just simplifies that process to a 1-click install.
https://github.com/dgtlmoon/changedetection.io
Self-Hosted, Open Source, Change Monitoring of Web Pages
Know when web pages change! Stay ontop of new information!
Live your data-life pro-actively instead of re-actively.
I use this app on CapRover and it works nicely.
Would be nice to have on Cloudron, although I accept not life-changing.
And I think there are various systems like this : I don't how this ChangeDetection.io compares. I just like the ease of use and UI.
Dockerfile available in their repo.
I made an attempt at self-packaging, but getting some errors, which I am investigating.
@robi very interesting thought : well the headline at least !
I fear the amount of work involved which takes @staff away from further developing cloudron, and more importantly the risk to cloudron stability of trying to put another system "alongside" in some ways.
The stability of my cloudron instance is valuable to me, so I wouldn't want it to be at risk through some architecture change or integration of another 'eco-system'.
BUT ... given that a container is a container, maybe the risk of a supporting a "bare isolated container" (e.g. docker run blah blah or docker-compose up -d) outside of cloudron email, backup, volumes, domain/dns might be acceptable to all.
I have a CapRover instance and like some parts of its approach, but I find many apps packaged for CapRover just don't work. Demonstrates the importance of 'opinionated packaging'.
I'd probably lean more towards a Portainer type approach, which seems a lot more robust than CapRover. A Cloutainer perhaps
But heck, what do I know.
Certainly interested how more expert techs see viability of this idea, which is a good one.