This documentation is here to provide all the basic concepts and vocabulary needed to understand app packaging.
We will detail what a YunoHost application package is, how it works, how to make your own package and how to find help if you need it.
The ability to easily install applications from a catalog is a key feature of YunoHost. While you dive in the process of YunoHost application packaging, you should remember these key principles:
The admin should not have a PhD in computer science to be able to install, configure and use your application: try to assume that the admin doesn't know about advanced computer concepts;
Less is more, Keep it simple!: don't overcrowd the admin with a dozens technical questions;
Things should work out of the box: for example, the admin should not have to manually finish the installation process by manually filling in database credentials;
YunoHost app packaging is not just about installing sources and dependencies: it's also about maintenance (upgrade, backup...) and integrating the app in the YunoHost ecosystem (NGINX, SSO/LDAP, Fail2Ban, application catalog, UI/UX...)
Before diving in, this documentation assumes that:
You are also encouraged to join the app packaging chatroom to ask any question you may have!
At some point, you will also want to have a dev/test environment, either using VirtualBox or LXC/ynh-dev which is meant for the core but can totally be used for developping apps. You can also setup a dev/test VPS on your favourite hosting provider, or even develop on your prod if you like to live dangerously;).
Many things in YunoHost, and YunoHost app packaging format, are historical or were designed in an organic fashion. Thus some aspects may legitimately feel old.
The "v0" of app packaging consisted in writing raw bash scripts with no real standardization/constrain.
Over time, recurrent steps (such as installing dependencies with apt, or setting up the NGINX config) where formalized into standardized bash functions, aka "helpers". This pretty much marked the beginning of the "v1" packaging era.
Various tools were implemented to test the app and standardize their behavior.
After a while, a set of common practices and conventions emerged and is somewhat reflected and maintain in the
example_ynh template application. While it is tempting for dev-oriented folks to change variable naming schemes or refactorize the structure of scripts, it turns out that it is even more important to stick to the common set of practices (even though arbitrary and not elegant) to ease the maintenance of all apps by any member of the packaging community accross all repos!
Nevertheless, even though helpers existed, the inherent structure of apps was hard and boring to maintain with too many redundant pieces of code or filled with funky historical conventions. A new v2 format has been designed and added to YunoHost 11.1 in early 2023 in the hope to modernize and simplify app packaging and improve the UI/UX of YunoHost.
However, a future v3 format has yet to come to further simplify app packaging (such as taking care of NGINX/systemd/... configurations, removing the need to manually write remove/backup/restore scripts, etc.)
A YunoHost app consists in a Git repository. We encourage you to have a look at those code repository to get familiar witch app repository structures:
example_ynhapp which illustrates all common features and recommended formatting
Among the file contained in a package, the most important ones are:
.jsonin the past)
_common.sh: common variables or custom functions included in other scripts
remove: the install and remove procedure
upgrade: the upgrade procedure
restore: the backup/restore procedures
change_url): changing where the app is installed in terms of web access url
app.src: contains the URL and checksum to downlowd the application sources
nginx.conf: the NGINX (=web server) configuration template for this app
systemd.service: the systemd service configuration template for this app
config.json/yaml/???: the app's configuration template
Roughly speaking, the install itself generally consists of the following operations (though these may vary depending on the complexity and technologies used by the app) - not necessarily in that exact order:
settings.ymlwith the admin's answers to the install form
installscript is ran and typically does:
Unless you really want to start from scratch or from
, one common practice is to identify an app similar to the one you're trying to package - typically because it relies on the same technologies - clone the corresponding code repository, and adapt the various files.
Found errors? Think you can improve this documentation? Simply click the Edit link at the top of the page, and then the icon on Github to suggest changes.
Powered by Grav + with by Trilby Media.