Installing and looking after applications

An application is the software your website actually is: WordPress, a forum, tomorrow a shop or an analytics package. You will find them under Accounts → your account → Applications.

That page has one row per installation, not per website — a website can carry two, for instance WordPress on yourdomain.com and a forum on yourdomain.com/forum. Every row is named so you can read it at a glance:

wordpress:yourdomain.com
phpbb:yourdomain.com/forum

The application first, then the place. That is how you can see what is where, and it is why two of them can sit in the same directory tree without getting in each other's way.

Installing something

Press Install an application, top right. A panel slides in beside the list — the list stays readable, because it holds the answer to the question you are asking yourself: is there already something on this website? The panel runs in four steps.

Step 1 — Application. Everything your hosting provider offers, side by side, each with one sentence saying what it is. An application this platform does not update says so on its card: You update it.

Step 2 — Place. Pick one of your own websites from the list; you do not type it. If your domain is not there, it has not been created as a website yet. Below it is the subdirectory: leave it empty and the application lands in your website's main directory, reachable at https://yourdomain.com/. Fill in forum and it lands at https://yourdomain.com/forum while your main site stays where it is. This is how you put two side by side.

As soon as both are known the server checks whether it can be done — before a single question about the administrator is asked. If it cannot, a red block gives the reason here and you cannot go on. See the next section.

Step 3 — Settings. Two questions: the title the application shows (you can change it inside the application later) and the administrator's e-mail address, where the application writes to its administrator about a forgotten password or a notification.

Under More settings are three you usually do not need:

• Version. The newest release your server's mirror carries, unless you choose another. The list says when each release came out and how big it is, and a release that closes a security hole is labelled as one.
• Administrator login. Leave it empty and it is your hosting account's name.
• Language. Only for applications that publish a separate release per language — WordPress does, most others do not. If nothing is offered, the application ships in one language and there is nothing to choose.

Step 4 — Confirm. Everything you chose on one screen, plus what is about to happen, in order: the target directory is checked, a database is created and the files are fetched, the application is set up, and if it goes wrong after unpacking the engine rolls it back itself. Then you see the administrator password once. Save it — it is not stored anywhere, not even by your hosting provider.

Nothing is created until that last button. Close the panel part way and your account is exactly as it was. If the server refuses the install, the panel stays open with the reason in it and your answers still in place, so trying again is one press rather than a second form.

A directory that already holds a website is refused. There is no button to override that, on purpose: an installer that can write over a live website will do so eventually. If you really want to start over, empty the directory in the file manager first, where deleting is what the screen is for.

When an application cannot run here

As soon as you have chosen an application and a website, the server checks whether it can — still on step 2, so before anything about the administrator is asked. If it cannot, a red block gives the reason and what to do about it, and you cannot get past that step. Step back and pick another application and the message goes, while the website you already chose stays chosen.

There are three kinds of reason:

• Your website's PHP version. Every application states its own. Joomla 6 will not start below PHP 8.3; PrestaShop 8.2 refuses everything above 8.1. The message names only versions this server actually offers, and you change it on the website's own page.
• A missing PHP extension. The message names the command and the screen that switches it on.
• The place. One application is particular about it: a Laravel application works out which page you asked for from the path in the URL, and cannot be told that its own path starts halfway down one. It belongs in a website's main directory or on a subdomain, not in a subdirectory.
• How many more files your account may create. This is the reason that surprises people most often, and it is not about disk space. These applications are file-heavy — a MediaWiki brings about 34,000 files, a Drupal about 34,000, a Nextcloud about 30,000 — and a hosting account has a limit on the number of files as well as on their size. Run into it and the unpacking stops halfway, with a message about disk space while the disk is half empty. So the server counts first. The message says how many files the release brings, how many more your account may create, and what to do about it: tidy up files you no longer need, or have your administrator raise the limit. Nothing is unpacked while the answer is no.

The catalogue, application by application

Matomo: the last three screens are yours

Matomo has no command-line installer. That is not your provider's choice but Matomo's own: its installation is a wizard in a browser, and there is no command anywhere in it that creates an administrator.

So what Install does is: place the files, create a database, and show you that database's details once. Then you open your website, walk through Matomo's own three screens, and fill those details in where Matomo asks for them.

Nobody else can finish that wizard for you: its first screen asks for the database password, and you are the one who has it.

After that it is an application like any other — updates take a restore point and roll themselves back, exactly as above.

Laravel: installed, not updated

A Laravel application is a starting point you build on yourself. From the moment it exists, the versions of its parts are pinned in your own composer.lock — and you move those, not your hosting provider. Update now is therefore refused, with that reason. Restore points and restores do work: those are about your work rather than about a release.

The website is served out of the public/ directory. CoreCP arranges that with an .htaccess in the main directory, which at the same time shields your .env and the framework's own directories. After every change the server fetches your .env over the web and fails the change if your website hands it over — that file holds your database password and the key that signs every session.

MediaWiki: a wiki, the way Wikipedia is one

MediaWiki is the software Wikipedia runs on, and it is just as much at home as a manual, a knowledge base or a club site. CoreCP installs it completely: the database is created, the wiki is set up, and you are shown the administrator's password once.

Two things to know:

• Your login starts with a capital letter. MediaWiki capitalises it itself, so an account called jansen signs in to the wiki as Jansen. The screen after the install names the login that actually exists.
• The card carries the version only. MediaWiki has no command that reports which extensions your wiki runs or checks its own files — that lives in the wiki itself, on Special:Version. So the card does not invent it.

Updating is something CoreCP does do in full: the files are replaced behind a restore point, and MediaWiki's own database updater runs afterwards.

OpenCart: the web shop of the catalogue

An OpenCart installation is a working shop straight away: the database is created, the sample catalogue is loaded, and the administration screen is at /admin/. Here too you are shown the administrator's password once.

Three things to know:

• Your password is shorter than with the other applications. OpenCart accepts at most twenty characters, so CoreCP makes twenty and shows you exactly the password the shop has.
• Updating stays inside one series. From 4.1.0.3 to 4.1.0.4 CoreCP replaces the files behind a restore point, which is precisely what OpenCart prescribes for such an update. A step to the next series (4.2) is something OpenCart does with its own wizard in the administration screen, under System → Maintenance → Upgrade, and CoreCP refuses that step with that pointer rather than performing half of it. What an updated shop keeps are the column widths it was originally created with; OpenCart publishes no migration for those and CoreCP does not invent one.
• The system/storage directory is shut off. It holds your sessions, your logs, your backups and the files customers upload, and OpenCart puts it inside your website. CoreCP closes it and checks over the web after every change that it is still closed.
• Your own .htaccess stays, even when the new version brings a different one. That file carries the web address your shop runs on plus whatever you put in it yourself — an update cannot know either, so CoreCP leaves it alone. You do get the new version's rules: they arrive as .htaccess.txt beside your own file. To see what changed, put the two side by side; take over only what you understand, and there is always a restore point from before the update.

PrestaShop: why it is listed and does not work

PrestaShop 8.2 refuses every PHP version above 8.1, and this platform ships 8.3 and newer because 8.1 stopped receiving security updates in December 2025. PrestaShop 9 is not published as a downloadable archive, so there is nothing to mirror. And its updates go through a module it fetches from its own marketplace, which this server cannot reach.

It is in the list so that you get a reason rather than silence. If you bring an existing PrestaShop with you on a migration, it is still recognised, measured, given restore points and put back.

Finding what was already there

Moved from another hosting provider, or uploaded something yourself once? Press Search for installations. The server looks in each website's main directory and one level below it, recognises what it meets, and puts it in the list.

Nothing inside your installation is changed by this. "Bringing under management" means exactly one thing: a row appears in the overview, so the rest of this page has something to act on.

It works the other way too. Stop managing removes that row and leaves every file exactly where it is. The next search finds the installation again.

The "Measured" column, and why it is there

Every installation says when it was last looked at, and how deeply:

• full — the application itself was asked about its version, its components and the state of its files. WordPress can do that.
• version only — only the version on disk was read. Whether something newer exists is what your provider's catalogue knows; the application itself was asked nothing.

That distinction is there because it is honest. A screen that prints "0 updates" for every application is saying something nobody checked for half of them — and the day that goes wrong is exactly the day it matters.

Measure again takes the measurement now instead of waiting for the server to do it on its own schedule.

Updating, and what happens when it goes wrong

Open an installation and choose Update now. Four steps sit behind that one button:

1. A restore point is taken: a copy of the files and of the database.
2. The update runs.
3. The server checks your site: do the pages still answer as they did, is there a new PHP error in your log, has the page not suddenly halved in size.
4. If the answer to any of those is no, the restore point is put back automatically — files and database.

You do not have to be there and you do not have to switch anything on. The History tab shows afterwards what happened, which check failed it, and whether anything was rolled back.

Under Policy you set what the server may update on its own: nothing, security updates only (the default), or everything. The whole list above still applies — automatic updating without a restore point does not exist here.

When that automatic updating happens

You choose what may be updated automatically; your provider chooses when. That is a window of a few night-time hours, separate from the server's own maintenance window — because that one may reboot the machine, and a reboot in the middle of a database migration is exactly what an update must never meet.

Three things that nightly round will not do:

• Update without a restore point. If an installation has that switched off, the round skips it and says so.
• Touch something that is not ready for it. A Matomo whose wizard was never finished is skipped rather than attempted.
• Jump to a new major number. Joomla 5 to Joomla 6 is not an update but a migration: the database changes with it, and your extensions have to have made that step too. With your policy on security updates that never happens by itself. The waiting release still shows on the card, so you can choose it yourself when it suits you.

If it goes wrong you hear about it

If a nightly update went wrong, or your website was put back from its restore point, that is on your overview the next morning and you get a message about it. The message says the important thing first: your website is serving — on the version it had just before the update — and what is still waiting is the update itself.

The same goes for a plugin, theme or extension on a live website that turns up in the list of published vulnerabilities. Where your policy takes security updates, it is closed by itself in the next window and you do not have to do anything; where your policy is "none", the hole stays open until somebody updates the component or switches it off.

For administrators: the server's own window

If you manage the server, the block Unattended website updates sits below the list: the switch, the window, when the next round runs, and how many installations on that machine each policy covers. That last one is there on purpose — whoever flips this switch is entitled to see the size of what they are switching on.

Trying the rollback for yourself

The Overview tab has Prove the rollback. That button really runs the update and then breaks the application on purpose, so the checks fail it and the restore point goes back.

It is not a simulation. Your site is broken for half a minute and then it is back, on the version it was on before the update. Do it once on a quiet afternoon and you will know the safety net works before you need it.

Taking a site offline while you work on it

Sometimes you need visitors to stop arriving for a while: you are importing three thousand forum posts, or moving a shop's product catalogue. Maintenance mode is on the Overview tab of an installation.

It uses the application's own switch — phpBB's Disable board, Joomla's Offline, WordPress's own maintenance flag — so your application knows it is offline too. Its own admin panel says so, its own scheduled tasks stand down, and nothing on the platform holds a second opinion about whether your site is serving.

Where the application has room for it, you can type one line for the visitor ("Back in an hour"). Where it has not, the panel tells you afterwards which part it could not use, instead of quietly dropping it.

Not every application has such a switch. MediaWiki, Matomo, OpenCart and PrestaShop keep theirs in a configuration file that only you and their own admin panel should edit, and Laravel's belongs to the application you wrote. The screen says so instead of offering a button that would refuse.

Turning it off is one button. An installation that is offline is marked as such in the list, and the heading counts them, so it cannot quietly stay off after the work is done.

Doing something to several at once

Tick the box in front of an installation and a bar appears above the list: Update, Take offline, Put back online and Measure again.

The run reports a line per installation, including the ones it did not do and why. That matters more than it sounds: an update over four sites that says only "done" cannot be told apart from one that covered two of them.

One rule the run keeps whatever you press. A bulk update never skips the restore point. If an installation's policy has that safety net switched off, the run leaves it alone and says so — you update that one on its own, while you are looking at it. Switching off the way back is a decision about one website, and a button that covers four is not the place for it.

WordPress sites are on both screens

A WordPress is an application like the others, so it is in this list too — with its restore points, the engine's history and its maintenance mode.

Everything that is specifically WordPress — plugins, themes, known vulnerabilities, the hardening checklist, the staging copy — is on the WordPress tab next door. Each screen has a link to the other, so whichever one you opened, you are one click from the rest of the answer.

From the command line

Everything above is also reachable over SSH, if your provider gives you that access:

$ corectl app recipes
$ corectl app requirements nextcloud yourdomain.com
$ corectl app requirements mediawiki yourdomain.com --path wiki
$ corectl app install mediawiki yourdomain.com --path wiki \
      --admin-email you@example.com --title "Our knowledge base"
$ corectl app install opencart yourdomain.com --path shop \
      --admin-email you@example.com --title "Our shop"
$ corectl app list --account youraccount
$ corectl app maintenance phpbb:yourdomain.com/forum --state on --message "Back in an hour."
$ corectl app bulk update --account youraccount --dry-run on
$ corectl app update phpbb:yourdomain.com/forum
$ corectl app snapshots --instance phpbb:yourdomain.com/forum
$ corectl app restore phpbb_yourdomain.com_forum-20260827T115718Z-s3xa5r \
      --instance phpbb:yourdomain.com/forum

See also: Your WordPress sites for everything that comes on top for WordPress specifically — the hardening checklist, the staging copy and the vulnerability alerts.

Where the application archives come from

The catalogue and every archive the panel installs come from the server's own package source — the same source its CoreCP packages come from, as the installer recorded it. On staging that is the build server; in production the production panel. A server without a recorded source says so when the catalogue is refreshed, instead of quietly using a test address.

Webmail and phpMyAdmin come from the same place now

The applications you install have always come from CoreCP's own mirror rather than from the internet at large — that is what Where the application archives come from above is about. Since this release the two applications the platform serves itself come from there too: the webmail at webmail.<your domain> and phpMyAdmin.

You will not notice the difference, and that is the point. Until now your server fetched those two straight from the projects' download hosts every time it set them up, and nobody checked what arrived. Now they take the same route as everything else here: a digest recorded once, checked against the projects' own signatures, and a file that does not match is not unpacked at all.

And, since this release, the web server itself

The same mirror now carries one thing that is not an application: the install archive of LiteSpeed Enterprise, the web server some of the machines run. It is there under a kind of its own — vendor — so it can never turn up in this catalogue as something you could install on a website.

Why it is there at all: it is the same question. For every file that ends up on a server it has to be written down where it came from and whether these are the bytes we recorded. A machine that fetches its websites' software from us and its web server from somewhere else has only half of that rule.