@timconsidine Yes, as mentioned by @humptydumpty and maybe start with, what tools do I need to have ready, and we should get our feet wet with in some cases, before starting, which are going to be in use during the whole process.
Cloudron CLI of course, what else?
A docker registry?
A GIT server?
A VPS with docker installed?
A Docker desktop version? (as well as the previous?)
How are they connected?
Maybe also an example of how one is (or should be) set up?
@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 ! 🍾
My use case is a little different than yours, so I don't have a tutorial, but Directus shouldn't be terribly hard to integrate with a JAM website.
I'm currently using it as a source for a static website using Elder.js. Elder.js isn't a JAM - it's a static site generator - but it works kinda similarly. Directus works wonderfully for it.
In most of the JAM stacks, there is a point for fetching data, and at that point (assuming your using Node.js here), you just use axios to call the endpoints that Directus exposes. When you want to create user accounts or whatnot, you make an API call to Directus.
I don't know how well Directus would stand up to a busy traffic website performance wise, but I'm pretty sure it would do a great job for a low-to-moderate traffic website. It might be a good thing to ask them on their Discord, they are very friendly.
A good way to picture Directus is that it's a nice frontend to an SQL database. So a lot of the things you'd care about with a regular database will matter with Directus. It's not going to automatically manage the accounts for you - but it's not hard to create a collection called 'Website Users' and just add a user account when someone registers on your site, and then verify it when they log in, managing the cookie or token appropriately.
This of course means it isn't 'low-code', but it isn't 'that's a ton of code' either. (As a note, if your going for posts and logins and the likes, I'd stick with JAM, and stay away from static site generators - static site generators are really built for sites that don't have live content, not that you can't fenagle your way around it, but it's not what they are built for).
If your looking for a bit more automation then that for logins... there's a few other frameworks that have built in libraries for user authentication, but the only one I remember really standing out as being 'easy' was Meteor (using their old UI framework called 'Blaze'). But Meteor is pretty different from Directus, and it's very opinionated, and usually requires a heavier server. Might not be what you are looking for.
One thing I will warn you on Directus... sometimes, major version upgrades (think 8.?.? -> 9.0.0) don't work quite as planned (at least in my experience). So if you see they are going to put out a new major version soon, it might be worth holding out until they do. Just my personal experience though.
@girish OK thanks, but I'm guessing there is some reason why they both default to Port 1935? is that the standard expected port for such things? I wonder if I'll hit any issues if I don't use that port...
The only issue would be if your streaming software cannot stream on any other ports, which is very unlikely. Simply set an entry for Owncast and one for PeerTube using the two different ports you set on your Cloudron.
For background, that file is source /app/data/env in the start.sh so it has to be a valid shell script. Such a behavior is happening in many apps, not sure how to document this or if we can add some extra trimming/filtering for such cases?
Ah if your instance is behind a NAT in your local network, then you have to forward a few ports from your router to the internal Cloudron server. 443 and 80 are basically the bare minimum. You can get some overview at https://docs.cloudron.io/security/#cloud-firewall
Further as @girish recommended, disable the cloudflare proxying at first until you managed to get it working without it. Just to rule out one possible point of failure.
The DNS records values in your case would be the public IP of your router. Then with the portforwarding rules, the connections will reach your internal Cloudron server. In case you are on an ISP connection where the IP might change on reconnect, you can consider using the dyndns feature of Cloudron.
@plusone-nick Yes, the are limitations but imho nothing extremly low. E.g. Microsoft SQL Server Express is limited to 10GB user data compared to the 12GB of Oracle XE - and despite of this limitation both products have their value and are widely used in small settings.
User authentication (which JWT tokens will do in this case) is currently not possible to customize and the current package does not yet support JWT tokens.
Regarding the config files, The ones used are symlinked into /etc and can be found in /run. Those however are recreated on every app restart so currently no permanent customizations can be made to those.
I can only reproduce the LICENSE.md issue and tried to create a symlink for it into /app/data but apparently their health checking code is not realizing the writeability through the symlink. We have to investigate further upstream then to see what solutions may be possible.