Docs - Alternative to Notion / Outline with OIDC, GDPR compliant, PDF Export (with template) etc...

[jdaviescoates]

This looks so great!

I'm praying to the @appdev and @staff gods that someone picks this up and packages it soon!

Have we already got any other Django and React based app packages?

[Neiluj]

• v3 is out: https://github.com/suitenumerique/docs/releases/tag/v3.0.0

[robi]

With Windsurf.io available, anyone can have an AI assistant help guide them on how to package apps for Cloudron.

UPDATE: link corrected to https://windsurfai.org/

[jdaviescoates]

@robi said in Docs - Alternative to Notion / Outline with OIDC, GDPR compliant, PDF Export (with template) etc...:

Windsurf.io

Wrong link. https://windsurfai.org/ ?

I've played a tiny bit (until my free credits run out) with https://replit.com/ which I have to admit was pretty damn impressive.

[robi]

@jdaviescoates oh thank you for the correction!

You will never run out with Windsurf if you use their Codeium base model. Every time you start a project though it will autoselect a Claude model. So just mind the dropdown before prompting.

[Gengar]

@Neiluj Wow this looks incredible !
And the image at the end of the github is priceless ,see below :

[timconsidine]

@jdaviescoates I’m using Windsurf and it is certainly good. Occasionally loses the plot and doesn’t always follow instructions correctly but still pretty darn good.

[jadudm]

The Docs installation requirements:

https://github.com/suitenumerique/docs/blob/main/docs/installation.md

This requires Kubernetes. Or, their "native" deployment method assumes Kubernetes.

From that page:

an OIDC provider (if you don't have one, we will provide an example)
a PostgreSQL server (if you don't have one, we will provide an example)
a Memcached server (if you don't have one, we will provide an example)
a S3 bucket (if you don't have one, we will provide an example)

In theory, it might be possible to take their repository, and deploy this in a single container as a Django app that uses

• Minio for S3
• The Cloudron-native Postrges instance
• The Cloudron-native OIDC
• ... mumble mumble memcached...

To make this viable, the right thing would be to extend Cloudron to provide a "native" Minio and Memcached instance for apps to use. (That is, have them present from time of install along side the various databases.) I could imagine making a product case for Minio, I think we'd struggle to convince girish and nebulon that the additional complexity of including memached everywhere was worth it.

Either way, this would be a major packaging effort. Without digging deeper, I'm going to assume that the Django app is not abstracted away from the services as well as we'd like, and that K8s requirement will make it very difficult to package/deploy to Cloudron. "Very difficult" means "many, many weeks of work, including changes to the core infrastructure of Cloudron."

(It looks like they have a compose (link) which I suspect is for local development of the app. It uses Redis instead of Memcached, still needs Minio, but also wants an Nginx instance and Celery instance... and Keycloack... and the app is in multiple containers/pieces...)

Long-and-short, there is no apparent easy path to bring this to Cloudron as a single-container/single Dockerfile application.

[robi]

Thanks for the breakdown @jadudm

It's clear these instructions and the intention behind the design is for a large scale deployment to replace the Google Suite.

Like NextCloud which can be deployed on local disk or S3 on install.

Hence I don't quite agree with the assessment above, as everything can be in one container and Cloudron does have most of the services needed, including other App examples that already have celery in use.

[jdaviescoates]

@jadudm said in Docs - Alternative to Notion / Outline with OIDC, GDPR compliant, PDF Export (with template) etc...:

Long-and-short, there is no apparent easy path to bring this to Cloudron as a single-container/single Dockerfile application.

[jadudm]

This post is deleted!

[Neiluj]

@jadudm Thanks for taking a look - this sounds more complicated than anticipated.

Please forgive my ignorance since I am trying to understand a bit better - I though that some elements for packaging this were already available from Cloudron infrastructure:

• nginx-ingress controller -> is this anything else that nginx being part of the package? if so I am pretty sure that this has already been done in other package
• an OIDC provider -> I think that this is definitely part of the cloudron infra. Many app packages use this now
• a PostgreSQL server -> I think that this is also part of the cloudron infra. Many app packages use Cloudron PostgresSQL as a service?
• a Memcached server -> Isn't this was Redis is for ? if so, does it differs from any other package?
• a S3 bucket -> while this is not integrated in Cloudron as a service, I believe other packages have a similar approach. For example, A mastodon Cloudron app is able to point to a S3 bucket. Is this any different here?

Again, I am probably mislead somewhere here and I have no experience (yet) in packaging any app, so I am grateful for any additional info here.

Also, If one was attempting to relay info upstream to hope to have this included in Cloudron one day, what info/request/wishes would be relevant to communicate?

Many thanks again,

[jadudm]

@Neiluj

I would welcome input from a member of the team on this.

Docker is intended to run a single process in a single container. When you want to run multiple services, you run multiple containers.

This is where you (typically) would use some kind of tool to orchestrate or compose those containers. For example, a docker-compose.yml will define a set of services, and how they connect and interact with each-other.

Cloudron is designed to host singleton containers. Unlike industrial-scale platforms as a service, it provides limited tooling for how to define connections to other services. The manifest allows you to connect to the services that exist; for example, I can say "connect to the Cloudron-provided Postgres server." However, I have no way to say "I have chosen to run an S3 server/Minio at location X, and please use it." As a result, it puts a significant burden on the user. Further, there is no way within the package to say "this should not boot if that service is not present." You have to write custom code in order to provide that logic.

Further, the Docs app itself wants to run multiple services. The frontend is separate from multiple backends in their design. The app itself has orchestration concerns and considerations.

So while I appreciate people saying "but it is all there!," we're not discussing what is required to make this a production-grade package.

1. You have to pull the codebase.
2. Study how it wants to be run, and decide how it can be run in Cloudron.
3. Write a custom build/containerization script for the app, compressing multiple services (that want to be in multiple containers) into a single container.
4. Write custom code to make sure external services that are not part of the Cloudron PaaS are present, and fail gracefully/in a way that a non-expert user can debug, so that they can add those services and connect them to the app.
5. Make this all automated and testable.
6. Maintain all of this while upstream rapidly evolves.

I'm forgetting things, I'm sure. I estimate 80-120h of work in this, and it is essentially devops work. It should bill at $85+/hour. Further, I'm notorious for underestimating how long it takes to develop features by a factor of 2x-4x. So, I think this is work worth at least $8K-$12K---to say nothing of having to maintain the package, against a large, fast-moving target. (And, while it is open source, governments tend to be very careful about accepting changes from third parties, because there are significant security and compliance burdens they must bear.)

Maybe I'm just accustomed to deployments in Ansible and Terraform, and am overstating the difficulty of this deploy. However, my experience is that when a system is designed to run one way, and you want it to run some other way, there's significant work involved.

So, in return, please forgive my ignorance. I may be misunderstanding things about packaging for Cloudron, and you may be right: this may be easier than I think.

I've started poking at a package for Planka to refresh myself on packaging, because it is a singleton Node app that only has Postgres as an external dependency. It is an example, in my mind, of an app that fits the Cloudron model perfectly. However, anything that wants orchestration beyond the core services Cloudron provides---especially when some of those services are custom components internal to the application itself---is, in my mind, significantly more effort.