Cloudron Forum

LoudLemur

Perhaps this would work as the Docker:
https://github.com/greenbender/inn-docker

Does anybody want to package INN to let people run a newsnet server using Cloudron?

LoudLemur

via Arya

🦾 Cool Applications for FrankenPHP

FrankenPHP's unique architecture—merging the Caddy web server with a modern PHP worker—unlocks a new tier of performance and functionality for PHP applications. Here are some exciting use cases it can support.

High-Performance Web Applications & APIs

Native PHP Frameworks (Laravel, Symfony):
- Benefit: Dramatically reduces response times by keeping the application bootstrapped in memory between requests. Eliminates the traditional PHP-FPM overhead.
- Ideal For: High-traffic SaaS platforms, enterprise applications, and complex APIs where every millisecond of latency counts.
Headless CMS Backends (Strapi, Directus - PHP ports/custom):
- Benefit: Provides incredibly fast content delivery for JAMstack sites, mobile apps, and other frontends. The worker mode ensures instant API responses.
- Ideal For: Developers building sites with Next.js, Nuxt, or SvelteKit who want a powerful, programmable backend without Node.js.
Real-time Applications:
- Benefit: While not a WebSocket server itself, its performance makes it an excellent backend for real-time features (handled by a separate WebSocket server) that require rapid API calls for data persistence and authentication.

️ Specialized Workloads & Microservices

gRPC Services:
- Benefit: FrankenPHP has built-in support for gRPC, a high-performance RPC framework. You can now write microservices in PHP that communicate efficiently with services in other languages (Go, Python, Java).
- Ideal For: Creating a performant, inter-service communication layer within a larger microservices architecture.
Queue Workers:
- Benefit: You can write long-running PHP scripts that process queues (e.g., for sending emails, processing video, generating reports) without worrying about script timeouts, as the worker is persistent.
- Ideal For: Offloading heavy, asynchronous tasks from your main web application.
Data Processing & ETL Pipelines:
- Benefit: The ability to run persistent scripts makes PHP viable for data-intensive tasks that require loading large datasets into memory once and processing them continuously.
- Ideal For: Building custom internal tools for data transformation, aggregation, and analysis.

️ Developer Experience & Modern Workflows

Static Site Generators:
- Benefit: The embedded Caddy server can serve built static files with exceptional performance. You can also build a dynamic SSG in PHP that runs at near-instant speed due to worker mode.
- Ideal For: Generating blogs, documentation sites, and marketing pages with the power of PHP templating but the speed of static hosting.
Development Environments & Tooling:
- Benefit: The single-binary nature of FrankenPHP makes it trivial to version and distribute. It's perfect for docker-compose setups or local dev environments, eliminating complex webserver configs.
- Ideal For: Teams standardizing their development environment to be fast, consistent, and easy to set up.
Serverless Functions (Early Stage):
- Benefit: With its quick cold start times (especially using the --worker script), FrankenPHP is a compelling runtime for PHP-based serverless functions or FaaS (Function-as-a-Service) platforms.
- Ideal For: Event-driven computing where you need to run PHP code without managing a full server.

Key FrankenPHP Features That Enable This:

Worker Mode: Persists your application in memory. This is the game-changer.
Automatic HTTPS: Powered by Caddy, it's set up by default.
Early Hints: Send 103 Early Hints responses to speed up page loads.
Built-in Compression: Automatic gzip and Brotli compression.
Single Binary: Easy to install, deploy, and run anywhere.

LoudLemur

@timconsidine I have updated the template. Thanks for this!

LoudLemur

@girish I can't see Danswer at the github now that it has rebranded. If @jagan still wants Onyx, a new thread would be a good occasion to support the request with the app request template, and gain some more upvotes.

Is the model and its training hidden for Onyx? Is Onyx's final answer generator OpenAI GPT-4 / GPT-3. 5-turbo?

AnythingLLM is somewhat similar to Onyx, and we have an Application Request for that already. AnythingLLM has a query mode which locks down responses to data you have provided:
https://docs.anythingllm.com/features/chat-modes

AnythingLLM also integrates with Ollama, which Cloudron already supports:
https://docs.anythingllm.com/ollama-connection-troubleshooting

AnythingLLM has a lot more contributors and seems less closed-box.

LoudLemur

AI Package Accelerator – Community FAQ (No-Code Blocks )

Reply “show me the optional scripts” to get the actual Dockerfiles/templates later.

️ General

Q1. Does this replace humans reviewing packages?
No. Every pull-request still waits for the same 2 human approvals that the official Cloudron repo requires today. The bot only drafts. You decide if it ships.

Q2. Who stops bad packages from overwriting my apps?
Every build is inside a NEW --name experimental-{app}-{n} instance on the experimental-app-store repo. Your production store is untouched.

System & Security

Q3. Who owns the hardware?
Day-1 we start on donated local GPU; if scale grows we pivot to Oracle/Amazon spot instances (< 50¢/hr). No long-term server is leased.

Q4. What if the bot forks malicious code?
Each MR diff is fully visible; same trust model as any manual MR. Build logs, line-by-line Dockerfile, image digests accompany every submission.

Q5. My server memory is tiny—can I still review packages?
Yes. Review is still pure GitLab diff + local VM test, exactly the same as before.

Cost & Transparency

Q6. Any hidden costs to Cloudron GmbH?
Zero. Budget is public (Google Sheet): every watt-hour is logged; if monthly spend creeps past $5 we simply pause builds until next funding sprint.

Q7. Where do the credits come from?
Bronze/silver sponsors + community fund (GoFundMe link). Donation receipts are posted weekly on that sticky thread.

🧪 Pilot Scope & Timeline

Q8. How many packages count as “pilot success”?
We target 5 100 % passing packages delivered in ≤ 14 days. If success rate < 20 % we auto-shutdown.

Q9. What prevents infinite loops?
Cycle count, 45-minute per-build timeout, OOM killer, “no-change” counter > 10 triggers immediate abort. Bot stops itself.

Q10. What stops the bot from resurrecting dead apps?
Queue is refreshed daily—an app dropped by maintainers is removed from queue script immediately.

Community Workflow

Q11. How do I add my pet app?
Post title includes tag #queueWIP. After 3 unique reactions in that thread the entry is auto-imported.

Q12. Who moderates the queue?
Any maintainer can +1/-1 items via GitLab CLI comment; human writes final decision.

Q13. Can I see live logs?
A sticky thread refreshes every 3 minutes with a TSV of build status: app, cycle#, exit code, short error preview.

Edge Cases

Q14. What if upstream deletes their GitHub branch mid-run?
Build fails, robot posts diff with “branch gone” note, humans re-queue.

Q15. What happens if Docker Hub rate-limits?
Spot instance silently rotates to another registry mirror; failure posted back, no stuck loop.

Q16. How do we cope with package.yaml typos only visible after install?
Post-build test container runs Cloudron linter + sentinel checks (curl localhost:3000/healthcheck)—still 100 % human eyeball before merge.

Q17. Can the bot push to stable channel?
No built-in ACL allows that. Only experimental-app-store repo receives merge requests.

Q18. What if I hate this idea?
Reply “STOP” in sticky thread; maintainers hard-kill runner; zero reversions needed.

Q19. I only trust hand-written Dockerfiles. Is there a manual only tag?
Yes: append label manualOnly in title and the bot ignores it forever.

Need the copy-paste scripts?
Reply with a single word "beep" under this post and I’ll drop a follow-up comment containing Dockerfiles, hook JSON, queue polling script, and exact GitLab YAML additions.

LoudLemur

Is this worth a try? Proposal created by AI:

Community-Driven AI Package Accelerator (Proposal v1.0)

Everyone loves new apps, yet no one loves the grunt-work of writing Cloudron packages.
This proposal outlines a lightweight, opt-in system that lets the community queue desired apps and have an AI runner spit out buildable, review-ready Cloudron packages—without handing final say to a computer.

1. Quick Elevator Pitch

Problem: 1,000 wish-list posts, finite volunteer hours.
Solution: A single shared AI runner that (a) hears community votes, (b) produces a draft package, (c) submits a GitLab merge-request, then (d) stops unless you green-light it.
Guardrails: every package still goes through the same human review that exists today.

2. Overall Flow

Forum tagging
- Any wish-list topic that gets 3 up-votes from different users is auto-queued.
Robot build
- AI reads the upstream Git repo, spins up a containerised build loop, generates PR.
Rich feedback
- Initial success/failure summary and a raw diff posted back in the same thread.
Human gate
- Maintainers still merge or reject. The bot may retry only if upstream source changes or if maintainers requeue explicitly.

3. Scope Boundaries (Keep It Simple)

Runs one package at a time to cut waste and keep logs readable.
Fresh snapshot after every out-of-memory kill or timeout (max 45 min).
No monetary cost to Cloudron GmbH; hardware lives on donated compute + spot credits.
No automatic “push to App-store”; each MR still needs two human approvals.

4. Accountability & Transparency

Item	How It’s Visible to Everyone
Build log	Pastebin link dropped in the same wish-list thread in real-time
Model version + seed commit	Script header auto-commented atop every generated Dockerfile
Queue status	Simple thread sticky—bots only bump every time the queue changes
Burn-rate	Solo ingredient: `$cloud-credits_spent / week` reported once a week in that sticky

5. Funding & Hardware Options

Phase 0: Local GPU (RTX 5090 32 GB) donated by @raindev—today
Phase 1: If success rate < 80 % after 100 packages, migrate to Oracle A100-40G spot (~ 45 ¢/hr) for LoRA fine-tuning bursts.
Goal: never exceed $5/month total cost averaged across 50 queued apps.

6. Call-Out for Volunteers

We need:

Queue admin: maintains the sticky thread; updates status daily (15 min/day task).
GPU oracles: anyone can spin the same image in cloud or locally and sync via S3 bucket.
Domain experts: confirm LDAP, backups, update docs (same reviewers we already have).

Reply below with the exact string “I can help + my role” and I’ll tag you in the task board.

7. Proposed Next Steps (14-day sprint)

Day	Task	Owner	Easy Check
1	Collect top 50 wish list links	community	spreadsheet open
2	Write Docker script that clones repo → test → diff	raindev	ran against ntfy
5	Add NodeBB webhook that posts on +3 votes	Any JS volunteer	MR ready
7	Announce pilot sticky thread	@forum-mods	traffic spike
14	De-facto go/no-go based on delivered packages & repo maintainers’ mood

8. Worst-Case Kill Switch

If feedback loop pushes < 20 % acceptance after 20 packages, the pilot halts automatically.
GPU shuts down; only curated wish-list list remains online.
Reset to status quo—nobody owes anyone anything.

Appendix — Code & Helpers

None embedded above to keep the thread readable.
If maintainers want Dockerfiles, hook samples, loRA snippets, queue polling scripts, etc. just reply “🩴 CODE” and I’ll paste everything in the very next comment.

Ask questions, flame away, or give a thumb-up—let’s make more apps show up without burning more people out.

LoudLemur

Pressbooks might be a better option:
https://forum.cloudron.io/topic/14188/pressbooks-on-cloudron-open-source-book-publishing-platform

LoudLemur

Main Page: https://pressbooks.org/
Git: https://github.com/pressbooks/pressbooks
Licence: GPL v3.0
Docker: Yes
Demo: https://pressbooks.com/ (SaaS demo, self-hosted demo not publicly available)

Summary: Pressbooks is an open-source book publishing platform built on WordPress Multisite, designed for creating and publishing books in multiple formats, including PDF, EPUB, web, and various XML flavors. It uses a CSS-driven theming/templating system and is widely used by educational institutions, academic presses, small publishers, and individual authors for producing open educational resources, textbooks, scholarly monographs, and more. Pressbooks supports PHP 8.1 and WordPress 6.6.1, and its open-source nature allows for self-hosted deployments. A Docker-based local development environment is available via the pressbooks/local-dev-environment repository, leveraging Lando/Docker for testing and development.

Notes: Pressbooks is a powerful tool for anyone looking to publish professional-quality books, especially in educational or academic contexts. Its integration with WordPress Multisite makes it familiar for WordPress users, while its export capabilities cater to diverse publishing needs. The availability of a Docker-based local development environment

suggests potential for a Cloudron app, though it may require additional configuration for production use. A concern is that Pressbooks is designed for fresh WordPress Multisite installations, not existing blogs, which could complicate integration for some users. The active development (latest release v6.31.2 on July 30, 2025) and community support make it a promising candidate for Cloudron.

Alternative to / Libhunt link: No direct Libhunt link available for Pressbooks alternatives, but comparable platforms include BookStack (https://selfhosted.libhunt.com/bookstack-alternatives) and GitBook for book publishing and documentation.
Screenshots: Pressbooks Logo, Sample Pressbooks Dashboard

Notes on Docker State: The Pressbooks project provides a Docker-based local development environment through the pressbooks/local-dev-environment repository, which uses Lando/Docker to provision a Pressbooks instance for testing and development (). This setup includes dependencies like pressbooks/pressbooks and pressbooks/pressbooks-aldine via Composer (). However, there is no official production-ready Docker image for Pressbooks in the main repository

. For Cloudron integration, the development Docker setup could serve as a starting point, but additional work may be needed to create a production-ready Docker image, including proper configuration for WordPress Multisite and dependencies like PHP 8.1 and WordPress 6.6.1 ().

This app request is experimental and was created with AI.

LoudLemur

@mario https://forum.cloudron.io/topic/12472/please-use-this-template-to-make-an-app-wishlist-request/8

LoudLemur

BTC Pay Server - what is the latest? We need it!

@timconsidine, is this application on your radar?

LoudLemur

An error in the tutorial is the most likely explanation, I think. I will try and think back to what we were doing and see if we remember something else. Restarting from scratch might be the best idea, though you have probably tried that several times already. Maybe the browser has a cache of the page or something like that...

LoudLemur

@rstockm Have you tried using the cli to extract the files from the zip directly into the root, instead of into a folder as usually happens? If you restart from there, you might have more success.

LoudLemur

AMD are hosting GPT-OSS-120B on hugging face and it is available gratis and fast:

https://huggingface.co/spaces/amd/gpt-oss-120b-chatbot

LoudLemur

chown -R www-data:www-data .

LoudLemur

Quick answer:

```mv linkstack/* .
mv linkstack/.* . 2>/dev/null
rm -rf linkstack/

and chown:

To fix this issue, which we also had, ensure you extract the .zip contents to (not to another folder) and that you have fixed the ownership to www-data:www-data. It was easier to sort this using the terminal in the LAMP application.

In bash terminal, or whatever the name of your zip file is:

unzip linkstack.zip
ls -la

You’ll probably see a folder like LinkStack-main/ or linkstack/. Move its contents to the current directory:

mv LinkStack-main/* .
mv LinkStack-main/.* . 2>/dev/null
rm -rf LinkStack-main/
rm linkstack.zip

Then verify:

ls -la

You should now see files like index.php, artisan, .env.example etc. directly in /app/data/public/.
After that, restart your LAMP app (perhaps you named it linkstack) and visit https://linkstack.whateveryourwebsiteis.com - you should now see the LinkStack setup page!

If you go into the terminal, and run ls -la, you should see:

/app/data/public# ls -la

total 16
drwxr-xr-x 3 www-data www-data 4096
drwxr-xr-x 4 www-data www-data 4096 …
-rw-r–r-- 1 root root 1342 Dec 10 2024 README.md
drwxr-xr-x 13 root root 4096 Dec 10 2024 linkstack

You will see the linkstack folder was created. Now, move its contents up to the current directory:

```mv linkstack/* .
mv linkstack/.* . 2>/dev/null
rm -rf linkstack/

Verify what’s now in the directory:

ls -la

You should now see files like index.php, artisan, .env.example, etc. directly in /app/data/public/.
Then fix the ownership since some files are owned by root. Use chown

chown -R www-data:www-data .

(I can't get that chown command into a code block on the forum for some reason...)

(Please remember the dot at the end.)
Verify ownership is correct:

ls -la

LoudLemur

It would be lovely to have. I hope it happens. soon!

LoudLemur

@msbt Thanks! I updated the tutorial.

LoudLemur

Tutorial For How to Install Foundry on Cloudron

Here’s a step-by-step guide to installing FoundryVTT on Cloudron using the public image, as shown in your screenshots and the asciinema cast.

Prerequisites
You have a working Cloudron server.
You have the Cloudron CLI installed and configured.
You have git and jq installed on your system.
You have a domain/subdomain ready to use for FoundryVTT (e.g., d20.cloudron.dev).
Step-by-Step Installation

Clone the FoundryVTT Cloudron App Repository
Open your terminal and run:

Bash

git clone https://github.com/BrutalBirdie/cloudron-foundryvtt.git

This will create a folder called cloudron-foundryvtt.

Change Directory
Move into the cloned directory:

Bash

cd cloudron-foundryvtt

Get the App ID and Version
Extract the app ID and version from the manifest using jq:

Bash

jq -r .id CloudronManifest.json
jq -r .version CloudronManifest.json

The output should be something like:

App ID: foundryvtt.cloudron.app
Version: 0.0.6 (or whatever is current)

Install the App Using the Public Image
Replace d20.cloudron.dev with your desired subdomain.

Bash

cloudron install --location d20.cloudron.dev --image brutalbirdie/$(jq -r .id CloudronManifest.json):$(jq -r .version CloudronManifest.json)

This command tells Cloudron to install the app at your chosen subdomain using the public Docker image.
5. Wait for Installation to Complete
The CLI will show progress: registering subdomains, waiting for DNS propagation, etc.
Once you see App is installed., you’re done!
6. Check Logs (Optional)
To check the app logs:

Bash

cloudron logs --app d20.cloudron.dev

Access FoundryVTT
Open your browser and go to https://d20.cloudron.dev (or your chosen subdomain).
You should see the FoundryVTT setup page.
Troubleshooting
If you get DNS errors, make sure your subdomain is correctly set up and points to your Cloudron server.
If you need to update or reinstall, repeat the steps above.
References
Cloudron FoundryVTT GitHub
Cloudron CLI Docs
FoundryVTT Knowledge Base
You’re done!
You now have FoundryVTT running on your Cloudron server. If you need to update, just pull the latest image and repeat the install command.

LoudLemur

We managed to install Linkstack on Cloudron. Here is a tutorial:

https://forum.cloudron.io/topic/14170/how-to-setup-linkstack-on-cloudron/2

LoudLemur

As of 2025-08-07, here are the links to download all the Linkstack community themes:

We found the linkstack application to be quite slow once it had been installed. For example, switching between one page and another in the admin panel took a while.

What do you think is the cause?

Common Causes of Slow Performance:
PHP-FPM/Apache configuration - Default LAMP settings may be conservative
Laravel framework overhead - LinkStack is built on Laravel which can be resource-heavy
Database queries - SQLite can be slower than MySQL for complex operations
Missing PHP opcache - PHP isn’t caching compiled code
Resource limits - LAMP app may have CPU/memory constraints
Quick Performance Improvements:
Option 1: Switch to MySQL (Faster than SQLite)
In your LinkStack admin:
Database settings → Switch from SQLite to MySQL
Use the credentials from /app/data/credentials.txt
Option 2: Enable PHP Optimizations
If you can access the LAMP configuration:
bash
Copy

Check if opcache is enabled

php -m | grep -i opcache

Option 3: Increase LAMP Resources
In Cloudron:
Go to your LinkStack (LAMP) app settings
Increase memory limit if available
Check resource usage in the app dashboard

Cloudron makes it easy to run web apps like WordPress, Nextcloud, GitLab on your server. Find out more or install now.

Cloudron Forum

LoudLemur

Posts

🦾 Cool Applications for FrankenPHP

High-Performance Web Applications & APIs

️ Specialized Workloads & Microservices

️ Developer Experience & Modern Workflows

Key FrankenPHP Features That Enable This:

AI Package Accelerator – Community FAQ (No-Code Blocks )

️ General

System & Security

Cost & Transparency

🧪 Pilot Scope & Timeline

Community Workflow

Edge Cases

Community-Driven AI Package Accelerator (Proposal v1.0)

1. Quick Elevator Pitch

2. Overall Flow

3. Scope Boundaries (Keep It Simple)

4. Accountability & Transparency

5. Funding & Hardware Options

6. Call-Out for Volunteers

7. Proposed Next Steps (14-day sprint)

8. Worst-Case Kill Switch

Appendix — Code & Helpers

Tutorial For How to Install Foundry on Cloudron

Check if opcache is enabled