Suggestions for improving the documentation

Corteza and the documentation have come a long way since the early days but there are always things we could improve.

Use this topic to provide feedback, opinion, and suggestion for improvements regarding our documentation.
This is a free for all; anything from the structure to the contents; anything goes, just keep it constructive.

Thank you in advance for all of your valuable feedback!

The biggest thing for me is that there are useful functions in the app, but it should be reflected in the documentation right after being added in releases - there’s no point in adding functionality if even the more advanced users can’t use it because they don’t know about it. As an example, Corteza has been somewhat compatible with MSSQL and some other SQL engines for a while now, but there still is not any documentation on how to create config for these databases.

There are also a lot of “todos” in the documentation itself.


Thanks for the feedback.
If anything else pops up, do let us know :pray:

I’m newer to programming full web applications. The thing that I am finding the most difficult to navigate is when to use which type of function and what each of them do. Also, workflows feel really convoluted. I would love a few demos that walk through different examples and talks about where each piece of data is coming from and how it’s moving through the workflow.


So you’d suggest improvements to the docs or workflows?

I suggest better documentation on using workflow low-code blocks (how to use each of the function types, how the data is connected (from modules to other modules or to internal fields) through each workflow step, and how to write effective references in building expressions.

I think the walkthroughs would be helpful to make it more beginner friendly.

1 Like

Makes sense, thank you

1 Like

From what I’ve seen on other platforms, I think the documentation needs:

  1. Adding some chapters like: fundamentals, getting started, building your first app.
  2. Changing the order of some chapters to be more user-oriented: from the least advanced to the most advanced.
  3. Including some simple app examples of what could be built with Corteza Compose.

Hi team,

Firstly, thank you to the Corteza team for all of your efforts. I’m so pleased that a truly unlimited (and frankly, quite polished) low-code platform exists, especially after trialling so many other open-source, self-hostable offerings with artificial limits. I’m looking forward to getting to know the Corteza ecosystem better.

As a new user, I’ve primarily been concerning myself with getting my new installation right. My biggest current gripe with the documentation is that the .env and docker-compose.yaml snippets are scattered across several pages, all quite different, some lacking seemingly essential things like setting up a persistent data volume for the server service.

I appreciate that the docs try to offer different solutions for different scenarios—offline vs. online, MySQL vs. PostgreSQL, etc. However, it seems that in all cases, the server’s /data directory should be persisted across teardowns—or I’m possibly wrong, in which case the docs don’t currently seem to make this obvious.

I don’t know what the best solution would be for this problem. Maybe one single mega .env file and one single mega docker-compose.yaml with ample comments indicating which sections to keep or remove depending on the situation, and then perhaps all other areas of the docs can link to that one location?