Applications and updates

Web Applications does two things: it's an inventory of the applications already in your home directory, and it installs new ones for you.

Each night, the panel scans your home directory for applications it recognizes: WordPress, Drupal, Joomla, Laravel, Symfony, Magento, Moodle, PrestaShop, MediaWiki, phpBB, Nextcloud, Ghost, Matomo, Node.js applications, and PHP applications managed by Composer. Supported Applications lists what this server recognizes now, and the marker file it looks for.

For each one, the panel records what's installed and which version, compares that against the project's current release and the published security advisories, and offers the update where it knows how.

An application you put in your home directory yourself is found on the next scan.

Install an application

Install an Application opens the chooser. Pick what to install, and the panel does the whole first setup:

• makes a new directory under ~/apps and unpacks the application into it
• makes a database, where the application needs one
• mounts the application on a website at an address you choose
• makes the application's administrator login

The page shows you each of these before anything happens, and nothing is overwritten.

The install runs in the background and takes a minute or two. The address answers about a minute after that, once the web server configuration catches up with the new mount. A page that doesn't answer right away is this delay, not a failure.

The administrator password is shown once

The panel shows the administrator login when the install starts and keeps no copy of the password. Save it before you leave the page. The login is a real user of your application and stays in its user list until you remove it.

An empty path replaces what the website serves

With Path left empty, the new application is served at the root of the website, and visitors no longer see what that website serves today. The panel keeps the old setting, and you can restore it from Mounts, but the change happens the moment the install ends.

The panel can't install every application it recognizes. The chooser says so for those, and Supported Applications has the whole picture.

What the list tells you

Column	Meaning
Application	The site's name, when the panel can read one from disk; otherwise its location.
Type	WordPress, Drupal, Laravel, and so on.
Version	What the installation itself reports. "unreadable" means the files are there but no version could be read from them, usually an incomplete upload.
Status	Up to date, Update available, New major version, or Unknown.
Advisories	How many published security advisories are open against the installation, and the worst of them. See Dependencies and advisories.
Location	The site that serves the application, or not served for a copy no website points at.
Last Seen	When the last scan observed the installation.

"Not served" still matters. A backup copy, an old cpmove extract, or a downloaded tarball in your home directory is a real installation with real code in it, and if anything can reach it by URL, an attacker can exploit it. Forgotten copies are a common way into a site. The panel lists them so you can update or delete them deliberately.

"Unknown" doesn't mean "up to date". The panel can compare against the project only when it has a release feed for that application, which today means WordPress and Drupal. Every other application is listed, but its status stays unknown; follow the project's own announcements for those.

If something is missing

The scan runs nightly. After installing something by hand, press Rescan to queue an immediate scan of your home directory. On a large account it takes a few minutes.

The tabs of an installation

Open an installation for its own screen. The tabs are the questions you can ask about it, and which ones appear depends on what the application can answer.

Tab	What it holds
General	What the last scan read: the version, the location, the address that serves it, and the update on offer. It runs nothing.
Properties	The application's own settings, such as its site title, address, and administrator email. Where the panel can change one, there's an Edit button beside it.
Uses	What the panel made for this installation and what it holds now: the database, the app server, and the website mount. Also what a removal takes with it.
Plugins, Themes, Modules, Components	The application's parts, with their versions and updates. The tab's name follows the application.
Permissions	What the application recommends for its own file permissions, and what the files are now.
Dependencies	The published security advisories against the application and the code it's built on.
Features	What the panel can turn on and off inside the application. See below.
Activity	Every job you asked for on this installation, newest first, with the tool's output.

Refresh at the top asks this one installation what it says now; Rescan on the list screen asks the whole home directory. On an account with many sites, use Refresh.

Sign in to an application

Sign In puts you in the application's administration area with no password to type, through a one-time link that expires in one minute.

The first time, the panel creates an administrator login inside the application for you and shows the password once.

The login belongs to the application

The account the panel creates is a real user of your application: it appears in the user list and in the notifications the application sends. Its password isn't your panel password, and changing one doesn't change the other.

Features

The Features tab holds what the panel can turn on and off inside the application. Each application offers a different set; the common ones:

Feature	What it does
Single sign-on	Adds a second way in on the site's sign-in page. People sign in with the same credentials they use for email and the panel, with the same passkeys and two-factor rules, and nobody keeps a separate password for the site.
File transfer	Gives the application a login it can write files with, so its own update screen works. See below.
Object cache and Page cache	Turn the site's caches on and off, and repair the cache rules.
Sends mail as	Sets the address and name the site sends its own mail as.
Restart the application server	For an application that runs as its own process, restarts that process. The site is down until it comes back.
Install the dependencies	Installs exactly what the application's lockfile names. The existing node_modules directory is replaced; no lockfile is rewritten.

A change here is a change to your application

These settings are written inside the application, not in the panel. If a result isn't what you wanted, undo it in the application.

Why single sign-on has a cost

A person who loses access to their panel account also loses their way into the site. And someone who set up the sign-in inside the site itself, not in the panel, must turn it off inside the site too; the panel can't turn off what it didn't turn on.

The file transfer login

WordPress asks for an FTP login before it writes files for its own updates. File transfer gives it one that never leaves this server.

Update plugins and themes from Dashboard → Updates. It asks for the password once and takes everything you selected.

The one-click buttons can't ask

The Install and Update buttons on WordPress's plugin and theme screens have no way to ask for a password, so they spin forever. Use Dashboard → Updates.

Permissions

An application says what its own directories need. The Permissions tab compares that against the files as they are, and Apply recommended permissions sets them.

The panel also applies them after every update of the application, because an update changes them.

This replaces what you set

The listed directories are set to what the application recommends. A permission you set by hand inside this installation is replaced.

Dependencies and advisories

The Advisories column on the list and the Dependencies tab are about published security advisories, not update status. An application can be the newest release and still carry an advisory.

There are two halves:

• The application itself. The panel checks the advisory databases against the version the last scan observed. To clear one of these, move the installation to a release the advisory doesn't affect.
• The code it's built on. The panel reads the exact versions from the application's lockfile and asks the package registry what's published against them. Whoever maintains the site moves that dependency forward.

The tab also names two kinds of dependency that carry no advisory today:

Kind	Why it's listed
Development dependencies	A test tool with a vulnerability can be deployed by accident, under a directory the web server serves. This has been a way into a site more than once.
Unmaintained dependencies	They work, and nothing is published against them, but their authors stopped maintaining them, so nobody will fix the next advisory.

The panel reads what's on disk. It doesn't test the site.

Not every installation can be audited

The dependency half needs a lockfile. An installation with no resolved project has nothing to audit, and the column says so. It can still carry advisories against the application itself.

Update an application

Open an installation to see the versions it can move to. The panel can offer two at once, and they're different decisions:

• A routine update inside your current major version: a security or bug-fix release. Take it on an ordinary day.
• A major upgrade to a new major version. A major version changes things, and a theme, plugin, or extension written for the old one can stop working. Plan it, and read the project's release notes first.

Both work the same way: press the button and confirm. The update runs in the background, so you can leave the page; the status goes Pending, Running, then Succeeded or Failed, and the page refreshes itself meanwhile.

The panel exports your database first, every time. The export goes to a file under .local/share/elpan/webapp-upgrade/ in your home directory, outside the document root, so nobody can download it. The most recent export per installation is kept.

The panel doesn't undo a failed update

If an update fails, the panel stops and tells you what happened. It doesn't return the files to the earlier version: a half-updated tree was never in a valid state, so a rollback is more likely to break the site than repair it. The failure message names the command that restores the earlier version and the location of the database export.

What must be true before an update runs

The panel refuses to update, and says why, when:

• it can't update this application (see below)
• the installation is incomplete: a WordPress without wp-config.php, or a Drupal without settings.php, has no database to migrate
• the database doesn't answer
• the files aren't writable
• another update of the same installation is already running

Applications the panel doesn't update

Frameworks. Laravel and Symfony are frameworks, not ready-to-use applications. What's installed is your application, built on the framework, with its own composer.json pinning its dependencies. Moving it forward (edit that file, resolve a lockfile, run your tests, deploy) is development work, so the panel never does it for you, but it still tells you when a new version exists.

Drupal 7. It's at the end of its life and has no automatic upgrade path. Moving to a current Drupal is a migration into a new site, not an update.

An application from a bare tarball, where the project expects Composer. A Drupal unpacked from a .tar.gz has no composer.json, so the panel has nothing to update. A Composer-managed Drupal is updated with Composer and your project's Drush.

Plugins, themes, and modules

For WordPress, the Plugins and Themes tabs list each one with its version and whether an update exists. Drupal's Modules tab does the same for Composer-installed modules. The panel reads this from the site each time you open the tab, so it's slower than General.

For Drupal, modules are updated on the Modules tab and core on the General tab. A module update moves its files, migrates the database, and rebuilds the cache.

This half matters more than core: an attacker usually enters a site through an old plugin, so a WordPress with a patched core and forty old plugins is not a patched site.

Update plugins one at a time, or press Update all to take every one with an update. It runs in the background like a core update, and when it finishes the panel shows the tool's own report of what changed.

• An inactive plugin still needs updating. Deactivating a plugin leaves its code on disk, and code on disk is still reachable. If you don't use a plugin, delete it rather than deactivating it.
• Auto-update in that list is WordPress's setting, not the panel's. The panel shows it so that "why did this update itself?" has one answer, not two.

Automatic updates

Each installation has an Automatic updates switch, off by default. Turn it on and the panel applies updates overnight without asking.

The nightly run has these limits:

• It stays inside your current major version. A major upgrade is always your decision.
• It runs only when a recent backup of your account exists. No backup, no unattended update. The database export before the update still happens; the two protect against different problems.
• It updates core only. Plugins and themes are never updated without a person.
• It updates one installation at a time per account.

With the switch off, you lose only the update itself. The panel still tells you when a new version exists.

Which sites to turn this on for

Automatic updates suit a site close to the standard installation. If your site has heavily modified themes or plugins you know to be fragile, leave the switch off and update while you watch.

Tell the panel to leave one installation alone

Give an installation the tag no-upgrade. That excludes it from everything: the nightly run and any bulk update your provider applies. It's the one way to say "never touch this", and every path in the panel obeys it.

The same work from the API or an AI assistant

The same operations are available over the API and to an AI assistant:

Tool	What it does
webapplication_list	Lists everything installed, with versions and whether an update exists.
webapplication_get	Shows one installation, with the exact versions on offer.
webapplication_audit	Reads the published advisories against one installation and what it's built on.
webapplication_scan	Queues a scan of your home directory.
webapplication_install	Queues an install of a new application.
webapplication_upgrade	Queues an update of one installation.

Reading needs the webapplication:readonly scope; scanning, installing, and updating need webapplication:readwrite. An assistant you ask to "update my sites" takes the routine update, never a major upgrade. For a major upgrade, you name the major version yourself.

Plugin updates, theme updates, the automatic-updates switch, and the tags are deliberately not available to an assistant. They're long-term decisions about how the panel treats your sites when nobody is watching, and a person makes them.