Cool, this is great, thanks! Even if it's not perfectly dynamic this will save me a lot of typing :)

Specifically wondering if there would be a programatic way to generate a list of application IDs and other information about the installs available in the platform. Even just a JSON feed would be pretty cool to keep a dynamically generated list of everything available.

Awesome, thanks!

An administrator should be able to reset a user's password on their behalf. The current ability to only send a password invite does not work well when attempting to integrate Cloudron with external systems that might need to sync a common set of credentials between the two. The Update User API call should be updated to allow a token with admin access to set the password.

You can have any number of domains, here is information on adding them https://cloudron.io/documentation/domains/. Once a domain is configured it becomes an optional location when installing an app. Let's Encrypt is setup automatically when you install an app in Cloudron.

FWIW switching to rsync fixed the original issue of this thread in my case. Figured I'd update here to let folks know.

@girish said in Toward a "Domain of One's Own":

In addition, when students logs into the Cloudron dashboard, they only see apps that they have access to.

Am I wrong that this is not how it currently works? When logged in as a regular user the Cloudron dashboard shows all installs on the server.

I want to think the hurdle of an admin needing to do the installing is something external tooling utilizing the API could accomplish. As long as the permissions thing is worked out properly. Scaling a Cloudron server for each student sounds pretty expensive to me so I'm definitely more interested in the first scenario if the friction can be removed.

Thanks, I'll try switching to rsync and see if that resolves it. The log seems pretty bare (I'm backing up to DO Spaces but I believe the failures were happening even with local filesystem). Will check back in if it persists.

I get emails fairly regularly with this message and I'm not sure where I would begin to troubleshoot.

{ stack: 'BackupsError: Backuptask crashed\n at /home/yellowtent/box/src/backups.js:487:29\n at f (/home/yellowtent/box/node_modules/once/once.js:25:25)\n at ChildProcess.<anonymous> (/home/yellowtent/box/src/shell.js:70:9)\n at emitOne (events.js:116:13)\n at ChildProcess.emit (events.js:211:7)\n at ChildProcess.kill (internal/child_process.js:395:12)\n at Timeout.<anonymous> (/home/yellowtent/box/src/backups.js:503:12)\n at ontimeout (timers.js:475:11)\n at tryOnTimeout (timers.js:310:5)\n at Timer.listOnTimeout (timers.js:270:5)',
name: 'BackupsError',
reason: 'internal error',
message: 'Backuptask crashed' }

Possibly a memory issue?

The licensing for Koken doesn't prevent an installer from being created for it and it's available on many hosting platforms today already. While obviously open-source is an ideal, I'd hope it's not a limiting requirement for anything that goes into the available apps. Koken is a great piece of software and sure, add the alternatives in there as well and let the user decide what they want to run.