All right, these are my impressions of Recogito Studio after the software demo: The software seems very mature. For users, there are: the possibility to reply to comments Comments can be private, read-only or only visible to certain groups You can create reading assignments and link them to documents Not only texts, but also images can be annotated annotations can be exported as CSV (PDF export is in the making) annotations can contain rich media (e.g. embedded youtube videos or images) For admins: can define different roles (instructors, students) Login is possible via SAML The software is GDPR-compliant in this short video, you can see how the software works: [image: 0610.mp4.gif] I pointed the team to this very thread, maybe someone of the developers might join this discussion. Again, I'd be very glad if we had Recogito Studio available on Cloudron.

@LoudLemur more proof that self-hosting is best approach (not immune but …)

@marylou yeah, or even just gath.io which does the job pretty nicely for most simple needs.

@girish thanks for your answer, even if it's too bad... As far as I can see, Kùzu is a database that can also be connected for storage to DuckDB or Postgresql, I don't know if that makes it more of a convenience for you, but in case... I wouldn't mind having a Supabase running outside of Cloudron connected to Kùzu managed on Cloudron.

Here is their Docker Hub page https://hub.docker.com/r/wisemapping/wisemapping

Is there any update here? We'd like to deploy it to our Cloudron instance

Hi, micmc! This is what Llama 3.1 405b has to say about the two: "VoiceChat (lhl/voicechat2): Features: Local AI voice chat system Uses WebSockets for communication Fully local (voice-to-voice) implementation Uses Whisper large-v2 (Q5) for speech recognition Utilizes Llama 3 8B (Q4_K_M) for language processing Employs tts_models/en/vctk/vits (Coqui TTS default VITS models) for text-to-speech Pros: Fast performance: Voice-to-voice latency is in the 1-second range on high-end GPUs Fully local: Doesn't require internet connection for core functionality Open-source: Available on GitHub for customization and community contributions Utilizes state-of-the-art AI models for speech recognition and language processing Cons: Requires powerful hardware: Optimal performance seems to be on high-end GPUs (e.g., AMD RDNA3 card) May have limited features compared to more established voice chat solutions Potentially complex setup for non-technical users Limited documentation available OpenWebUI: Features: Web-based user interface for AI interactions Docker and Kubernetes support for easy deployment Integration with OpenAI-compatible APIs Customizable OpenAI API URL Support for both Ollama and CUDA-tagged images Functions and pipeline support for extended capabilities Pros: Effortless setup using Docker or Kubernetes Flexible API integration (OpenAI, LMStudio, GroqCloud, Mistral, etc.) Web-based interface for easy access Extensible with functions and pipelines Active development and community support Supports multiple deployment options (pip, Docker, Kubernetes) Cons: Documentation may be lacking in some areas, making integration challenging Primarily focused on text-based interactions, unlike VoiceChat's voice-to-voice approach May require more setup for voice capabilities (if needed) Potential learning curve for utilizing all features and integrations Comparison: Focus: VoiceChat is specifically designed for voice-to-voice AI interactions. OpenWebUI is a more general-purpose web interface for AI interactions, primarily text-based. Deployment: VoiceChat seems to require local installation and configuration. OpenWebUI offers multiple deployment options, including Docker and Kubernetes, making it potentially easier to set up and scale. Flexibility: VoiceChat is focused on local, offline use with specific AI models. OpenWebUI offers more flexibility in terms of API integrations and customization options. User Interface: VoiceChat likely has a minimal interface focused on voice interactions. OpenWebUI provides a web-based interface that can be accessed from various devices. Community and Development: Both are open-source, but OpenWebUI appears to have more active development and a larger community. Use Case: VoiceChat is ideal for users needing offline, voice-based AI interactions with low latency. OpenWebUI is better suited for users who need a flexible, web-based interface for various AI interactions and integrations. In conclusion, the choice between VoiceChat and OpenWebUI depends on the specific needs of the user. VoiceChat is more specialized for voice-based AI interactions, while OpenWebUI offers a more versatile platform for general AI interactions with easier deployment options. Users prioritizing voice capabilities and offline use might prefer VoiceChat, while those needing a flexible, web-based solution with various integrations might find OpenWebUI more suitable."

Late to the party here but Kafka has my preference due to a few features it has over RabbitMQ. In the process of packaging it myself as a test

@mdegla upvote the original post

Will edit the main post here to remove those links

For folks who need to self host this app, I created a comprehensive tutorial. Create a fresh server, update and upgrade the system, install docker and docker compose with this one command. sudo apt-get update -y && sudo apt-get upgrade -y && sudo apt-get install -y apt-transport-https ca-certificates curl software-properties-common gnupg lsb-release && curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg && echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null && sudo apt-get update -y && sudo apt-get install -y docker-ce && sudo usermod -aG docker $USER && sudo curl -L https://github.com/docker/compose/releases/download/v2.26.1/docker-compose-`uname -s-uname -m` -o /usr/local/bin/docker-compose && sudo chmod +x /usr/local/bin/docker-compose && \ Clone the Repo git clone https://github.com/langgenius/dify.git Customize the .env file cd dify/docker cp .env.example .env I only customized the following variables. APP_WEB_URL=your_domain_name NGINX_HTTPS_ENABLED=true NGINX_SSL_CERT_FILENAME=cert.pem NGINX_SSL_CERT_KEY_FILENAME=key.pem Ctrl S to save, Ctrl X to exit the nano editor. cd - Create SSL Certificate Create ssl certificate at Cloudflare (open SSL/TSL tab and open Original Server) nano dify/docker/nginx/ssl/cert.pem Copy and paste the Cloudflare certificate, then Ctrl S, Ctrl X nano dify/docker/nginx/ssl/key.pem Copy and paste the Cloudflare SSL key, then Ctrl S, Ctrl X Deploy cd dify/docker docker compose up -d Upgrade cd dify/docker docker compose down git pull origin main docker compose pull docker compose up -d Setting Up Automated Backups for Dify Using Restic and Cloudflare R2 Step 1: Install Restic Connect to your server via SSH. Update your package list and install Restic:sudo apt update sudo apt install restic Step 2: Prepare Your Cloudflare R2 Bucket Create a new R2 bucket in your Cloudflare account if you haven't already. Note down the following information from your Cloudflare R2 setup: Bucket name Access Key ID Secret Access Key R2 Endpoint URL Step 3: Create the Backup Script Create a new directory for the Restic script: mkdir -p /root/restic Create and open the backup script using nano: nano /root/restic/backup.sh Copy and paste the following content into the file: #!/bin/bash # Set environment variables for Restic export RESTIC_REPOSITORY="s3:YOUR_R2_ENDPOINT_URL/YOUR_BUCKET_NAME" export AWS_ACCESS_KEY_ID="YOUR_ACCESS_KEY_ID" export AWS_SECRET_ACCESS_KEY="YOUR_SECRET_ACCESS_KEY" # Set the backup source BACKUP_SOURCE="/root/dify/docker/volumes" # Perform the backup restic backup $BACKUP_SOURCE # Prune old snapshots (keep last 7 daily, last 4 weekly, and last 12 monthly backups) restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune # Check the repository for errors restic check Replace the following placeholders with your actual Cloudflare R2 information: YOUR_R2_ENDPOINT_URL: Your Cloudflare R2 endpoint URL YOUR_BUCKET_NAME: Your R2 bucket name YOUR_ACCESS_KEY_ID: Your R2 Access Key ID YOUR_SECRET_ACCESS_KEY: Your R2 Secret Access Key Save the file and exit nano: Press Ctrl + X When prompted to save, press Y Press Enter to confirm the file name Make the script executable: chmod +x /root/restic/backup.sh Secure the script (as it contains sensitive information): chmod 700 /root/restic/backup.sh Step 4: Initialize the Restic Repository Set the environment variables (replace with your actual R2 information): export RESTIC_REPOSITORY="s3:YOUR_R2_ENDPOINT_URL/YOUR_BUCKET_NAME" export AWS_ACCESS_KEY_ID="YOUR_ACCESS_KEY_ID" export AWS_SECRET_ACCESS_KEY="YOUR_SECRET_ACCESS_KEY" Initialize the Restic repository: restic init Step 5: Set Up Daily Backups Open the crontab file: crontab -e If prompted to select an editor, choose nano by entering the corresponding number. Add the following line at the end of the file to run the backup daily at 3 AM: 0 3 * * * /root/restic/backup.sh > /root/restic/backup.log 2>&1 Save the file and exit nano: Press Ctrl + X When prompted to save, press Y Press Enter to confirm Verifying the Setup To ensure everything is set up correctly: Run the backup script manually: /root/restic/backup.sh Check the Restic repository for snapshots: restic snapshots Restoring from a Backup To restore your data: List available snapshots: restic snapshots Restore the latest snapshot: restic restore latest --target /path/to/restore Replace /path/to/restore with the directory where you want to restore the data. Done.

Just a bump to see if anyone wants to help me convert this into a custom Cloudron? Microsoft's statement is that SMTP Auth via Basic auth will be retired in September 2025. Which means SMTP via Office 365 will stop working on Cloudron if an alternative solution isn't prepared. This utility allows you to send and receive using oAuth2.0 which would provide a straight forward solution for Cloudron apps that don't natively support it. Also, it would bypass the requirement to have Port 25 open.