Cloudron Forum

Oh wow, lots of changes! Let us know if you need anything.

@vladimir-d In the future, I believe we should let the app handle most of it's configuration, environment-wise.

Variables such as RAG_EMBEDDING_MODEL, etc. are all set via the application UI and saved in the config.json file.

Now, for the initial issue of this topic, I've solved it by resetting the embedding model engine.

as @jdaviescoates notes, the SSO setting generally is only during install time, as changing auth backends later causes usually issues within the app and user mapping.

I guess the placeholder text is not ideal for that textarea but the default is to allow the app iteself to respond to the robots request. The docs state this more clearer https://docs.cloudron.io/apps/#robotstxt

"By default, Cloudron does not setup a robots.txt for apps. When unset, the app is free to provide it's own robots.txt."

So the default basically is not to allow all but to let the app handle it.

Handled with the email support.

Thanks for the very fast help!

LOL... I didnt look this topic created under App Wishlist

@girish Right. Forgot about this, using upstream's HOSTNAME variable to 0.0.0.0 works.

Though, I spoke too fast about the package working, I still have a runtime error after this 😕

Investigating.

Makes sense. Thanks for the insight, I'll close the PR as it's not relevant right now.

They also have a binary pgadmin4-web, used to install the web version on debian, red-hat based, etc.

The tricky part for Cloudron is the setup, there is a setup-web.sh script that needs to be executed to setup (and start?) the app that seemingly needs access to read-only paths.

Other than that, seems pretty straightforward and easily configurable through environment variables.

@girish

To make it more clear, I have made a template repository with all the files and scripts I usually use for my Cloudron apps.

In the future, we might benefit from adopting such a strategy for the Cloudron CLI init script by using these files as a template/starter Cloudron app project. It'd make maintenance easier, more uniform, and make the process less daunting for new app devs.

https://github.com/Lanhild/starter-cloudron

Got it. Thanks for the answer!

@fbartels Got it, makes sense. Maybe for the potential Cloudron package there could be an option or env variable to enable the dashboard, just like the Open WebUI package where you can toggle on/off the local ollama.

@Lanhild thanks, will check it out. Apps using sqlite cannot be considered stable until we figure a proper backup strategy. Cloudron's backup strategy is to copy files and this doesn't work well with databases in the data directory. The data can be inconsistent.

Also, given no automatic migration from sqlite to postgres, we might have to publish a completely new package

@Lanhild said in Teable: ✨ A Super fast, Real-time, Professional, Developer friendly, No code database:

https://github.com/teableio/teable

It is great to see you are still active in the community here, @Lanhild.
To encourage others to take a look and generate interest, including the following links and some screenshots helps when creating an App Wishlist request:

Main Page: https://teable.io/
Licence: GNU AGPL v3.0
Github: https://github.com/teableio/teable
Docker?: yes - https://github.com/teableio/teable/tree/develop/dockers
Demo:

brave_zkoB4Ks7yS.png brave_bmegGHJJax.png brave_2fWHxxLF3F.png

"Why Teable?
No-code tools have significantly speed up how we get things done, allowing non-tech users to build amazing apps and changing the way many work and live. People like using spreadsheet-like UI to handle their data because it's easy, flexible, and great for team collaboration. They also prefer designing their app screens without being stuck with clunky templates.

Giving non-techy people the ability to create their software sounds exciting. But that's just the start:

As businesses expand, their data needs intensify. No one wishes to hear that once their orders reach 100k, they'll outgrow their current interface. Yet, many no-code platforms falter at such scales.

Most no-code platforms are cloud-based. This means your important data sits with the provider, and switching to another platform can be a headache.

Sometimes, no-code tools can't do what you want because of their limitations, leaving users stuck.

If a tool becomes essential, you'll eventually need some tech expertise. But developers often find these platforms tricky.

Maintaining systems with complex setups can be hard for developers, especially if these aren't built using common software standards.

Systems that don't use these standards might need revamping or replacing, costing more in the long run. It might even mean ditching the no-code route and going back to traditional coding.

What we think the future of no-code products look like
An interface that anyone can use to build applications easily.

Easy access to data, letting users grab, move, and reuse their information as they wish.

Data privacy and choice, whether that's in the cloud, on-premise, or even just on your local.

It needs to work for developers too, not just non-tech users.

It should handle lots of data, so it can grow with your business.

Flexibility to integrate with other software, combining strengths to get the job done.

Last, native AI integration to takes usability to the next level.

In essence, Teable isn't just another no-code solution, it's a comprehensive answer to the evolving demands of modern software development, ensuring that everyone, regardless of their technical proficiency, has a platform tailored to their needs."

@girish Yeah that was it. It works now. Thanks!

@girish Thanks, that was it.