--- title: Applications template: docs taxonomy: category: docs page-toc: active: true routes: default: '/apps_overview' --- One of the key feature of YunoHost is the ability to easily install applications which are then immediately usable. Example of applications include a blog system, a "cloud" (to host and sync files), a website, an RSS reader... Applications can be installed and managed through the webadmin interface in `[fa=cubes /] Applications` or through commands of the `yunohost app` category. [center] ![Apps list](image://apps_list.png?resize=512&classes=caption "Apps list in the webadmin, with its Install button.") [/center] The application catalog and its categories can be browsed directly from the webadmin by clicking on the `[fa=plus /] Install` button in the apps list, or from this documentation.
Applications catalog
### Useful applications If you already have a website ready to be deployed, consider using a **Custom Webapp**. It allows you to easily setup a directoty into which you can upload your HTML, PHP, CSS, JS files with SFTP, and a database if needed. If you want to use YunoHost as a reverse proxy, i.e. serve an app from another server or an internal web server (think NodeJS, ruby, Python, ...), you can use the **Redirect app**. The Redirect app can also simply create shortcuts for your users in their SSO page. For more information on these apps, and for more application use cases, have a look to the [Tutorials](/tutorials) section. ! Be careful to stay reasonable on the number of installed applications. Each additional installation increases the attack surface and the risk of failure. Ideally, if you want to test, do it with another instance for example in [a virtual machine](/install/hardware:virtualbox). ## Installing and configuring an app Let's say you want to install a *Custom Webapp*. Before actually running the installation steps, YunoHost will usually have you fill in a form to properly set it up for you. [ui-tabs position="top-left" active="0" theme="lite"] [ui-tab title="From the webadmin"] ![Custom Webapp install form](image://app_install_form.png?resize=768&classes=caption "Pre-installation form of the Custom Webapp") [/ui-tab] [ui-tab title="From the command line"] ![Custom Webapp install form in CLI](image://app_install_form_cli.png?resize=768&classes=caption "Pre-installation form of the Custom Webapp in CLI") [/ui-tab] [/ui-tabs] ### Subpaths vs. individual domains per apps Among specific questions, forms usually ask you to choose a domain and a path onto which the app will be accessible. In the context of YunoHost, it is quite common to have a single (or a few) domains on which several apps are installed in "subpaths", so that you end up with something like this: ```bash yolo.com ├── /blog : Wordpress (a blog) ├── /cloud : Nextcloud (a cloud service) ├── /rss : TinyTiny RSS (a RSS reader) ├── /wiki : DokuWiki (a wiki) ``` Alternatively, you may choose to install each (or some) apps on a dedicated domain. Beyond the aesthetic, using sub-domains instead of sub-paths allows the possibility to move a service to another server more easily. Also, some applications may need an entire domain dedicated to them, for technical reasons. The disadvantage is that you have to add a new domain each time, and therefore potentially configure additional DNS records, restart the diagnostics and install a new Let's Encrypt certificate. This might look prettier for end users, but is generally considered more complicated and less efficient in the context of YunoHost, since you need to add a new domain each time. Nevertheless, some apps might need an entire domain dedicated to them, for technical reasons. If all apps from the previous example were installed on a separate domain, this would give something like this: ```bash blog.yolo.com : Wordpress (a blog) cloud.yolo.com : Nextcloud (a cloud service) rss.yolo.com : TinyTiny RSS (a RSS reader) wiki.yolo.com : DokuWiki (a wiki) ``` !!! Many applications integrate a feature that allows you to change the URL of your application. This choice between subpath and subdomain can be reversed in some cases via a simple manipulation in the administration interface. ### User access management The installation form usually asks whether or not the app should be publically accessible. If you choose to not make it public, only users logged in YunoHost will be able to reach it. !!!! After installation, this can be configured via the webadmin in the [Groups and permissions panel](/groups_and_permissions), or similarly via the command-line subcategory `yunohost user permission`. ### Instructions after installation Some applications need to give you instructions, URLs or credentials once they are installed. So remember to check the email of the first user account or the admin user selected before installation, if it was prompted. ## LDAP / SSO integration Applications that allow users to register may support integration with the LDAP / Single Sign On of YunoHost, so that users who connect to the user portal can be automatically logged in all these apps. However, some applications do not support this as it can be either not implemented in the upstream, or the package does not work on this part yet. This information is usually available on the README of the application package. ## Multi-instance applications Some applications support the ability to be installed several times (at different locations) ! To do so, just go another time in `Applications > [fa=plus /] Install`, and select again the application to install. ## Tile management Web applications can provide tiles available from the user portal, it is possible to choose whether or not to display them and redefine the text via the web administration interface `Applications > APP name > Operations > Manage labels and tiles` or via the command line: `yunohost app change-label "New text"`. ## Applications packaging Applications must be packaged manually by application packagers/maintainers. Apps can be integrated with YunoHost to support upgrades, backup/restore and LDAP/SSO integration among other things. If you want to learn or contribute to app packaging, please check the [contributor documentation](/contributordoc). ### Integration and quality levels Automated tests are being run regularly to test the integration and quality of all apps who were declared to be `working` by packagers. The result is a level between 0 and 8, whose meaning is detailed on [this page](/packaging_apps_levels). Some tests results may also be available [on this dashboard](https://dash.yunohost.org/appci/branch/stable). By default, only applications of sufficient quality are offered. When the quality of an application drops and until the problem is reolved, the app is hidden from the catalog to prevent its installation and its upgrades are put on hold.