I’d like to contribute and learn the hardway, by packaging an app.
I’ve been in the matrix chat asking help to “where to begin”. I then have read all doc and check everything about git which I didn’t knew at all.
There are 2 branches, dev & main. I get that I should use the main for stability.
I find all the files of the app in the “src” (source I think). The other are for docker I guess ?
But then it’s only done to be able to install it easily using docker and docker-compose.
I don’t really find the way to install / compile for yunohost app. I found that the langage using is typescript, so I dig into already pack app using this langage, and using video to match the best : Peertube, owncast & sync-in are using this langage and are able to handle videos sharing. I can may be compare, but what ? ^^’
I then am stuck. Dunno know where to begin. Some tips to help would be great !
I’ll check that and update this thread. I would really need this app professionally, that’s why I’ll begin with it. If I can get an app made “for docker”, that mean I could do every app as now they are almost all “made for docker”. So that’s the positiv point !
It’s the hardway as I said. I’m willing to try, and follow your advice. I’ll ask more question also I guess… Thank you for this path to take.
The reason its docker first has to do with multiple reasons
It’s not a single app, it’s a small stack a Next.js web app plus a separate background worker (video transcoding, thumbnails, notifications) it needs PostgreSQL, Redis, FFmpeg, and an S3-compatible store (either local or cloud provider) or bare metal local storage. That’s 4 to 5 moving parts that have to be wired together. The compose file is that wiring and keeps it simple.
Why Docker-only, in short:
Reproducibility / support. The image pins exact versions of Node, FFmpeg, the DB client, etc. Every install is identical, so I’m not chasing “works on my distro but not yours” bugs across dozens of OS/version combos. As a small project that’s the difference between sustainable and not.
The audience. ViTransfer is for videographers and studios, not sysadmins. The promise is: edit a .env (domain + a few secrets), docker compose up, done — and update by pulling a new image. Asking them to set up Node + Postgres + Redis + FFmpeg natively would lose most of them on day one.
Security. The image runs non-root (PUID/PGID), with no-new-privileges, an isolated network, a pinned/patched Alpine base, and the build fails on high/critical CVEs. One hardened image is far easier to keep secure than a sprawl of system packages.
Maintainability. Every extra packaging target multiplies testing + support. One supported path keeps the project alive.
For a YunoHost package: a fully native package would mean re-implementing all of that orchestration (worker, FFmpeg, S3, the lot) and maintaining it in parallel, I can’t commit to supporting that as a single person.
That’s the main reason I do not provide an install bare metal with all those single components as it’s build with docker only in mind from the get go and maybe that is lazy on my end, but im providing this FOSS and I’m trying to just provide something that works for me and is secure and maintainable to share it with others via the most accessible way and easy setup.
There’s no expectation you (MansiVisuals) will maintain the ynh package yourself, but some technical insight in case things go south (like I DO use psql 18 features, that’s mandatory) would be very welcome.
I have responded to your questions in the git issue.
Again its not that I do not know or do not what to help its just as I do not use yunohost or even know yunohost existed before this request so it has no value to me in general to make sure everything runs as it should on these packages and I do not want to be to blame when things go south or security isnt up to par with these packages. But I hope this helps you package it.
But again big disclaimer from my end that im not affiliated with the creation of these packages for yunohost.
or to be sad 