Applicaties installeren en bijhouden

Een applicatie is de software die je website eigenlijk ís: WordPress, een forum, straks een webshop of een statistiekpakket. Je vindt ze op Accounts → je account → Applicaties.

Op die pagina staat één regel per installatie. Niet per website — een website kan er twee dragen, bijvoorbeeld WordPress op jouwdomein.nl en een forum op jouwdomein.nl/forum. Elke regel heeft een naam die je meteen herkent:

wordpress:jouwdomein.nl
phpbb:jouwdomein.nl/forum

Eerst de applicatie, dan de plek. Zo weet je in één oogopslag wat er waar staat, en zo kunnen er twee naast elkaar in dezelfde map staan zonder dat ze elkaar in de weg zitten.

Iets installeren

Klik rechtsboven op Applicatie installeren. Er schuift een venster open naast de lijst — die blijft leesbaar, want daarin staat het antwoord op de vraag die je jezelf stelt: staat er al iets op deze website? Het venster loopt in vier stappen.

Stap 1 — Applicatie. Alles wat je hostingpartij aanbiedt, naast elkaar, elk met één zin over wat het is. Bij een applicatie die dit platform niet bijwerkt staat dat er meteen bij: Je werkt hem zelf bij.

Stap 2 — Plek. Kies een van je eigen websites uit de lijst; je typt hem niet. Staat je domein er niet bij, dan is het nog niet als website aangemaakt. Daaronder staat de submap: laat je die leeg, dan komt de applicatie in de hoofdmap van je website en is hij bereikbaar op https://jouwdomein.nl/. Vul je forum in, dan staat hij op https://jouwdomein.nl/forum en blijft je hoofdsite waar hij was. Zo zet je er twee naast elkaar.

Zodra allebei bekend zijn kijkt de server na of het kan — nog vóór er ook maar één ding over de beheerder gevraagd wordt. Kan het niet, dan staat er hier een rood blok met de reden en kom je niet verder. Zie de volgende paragraaf.

Stap 3 — Instellingen. Twee vragen: de titel die de applicatie zelf toont (later gewoon te wijzigen) en het e-mailadres van de beheerder — daar schrijft de applicatie haar beheerder op aan bij een vergeten wachtwoord of een melding.

Onder Meer instellingen staan er drie die je meestal niet nodig hebt:

• Versie. Standaard de nieuwste die de spiegel van je server draagt. In de lijst staat per uitgave wanneer die uitkwam en hoe groot hij is, en een uitgave die een beveiligingslek dicht is als zodanig aangeduid.
• Inlognaam beheerder. Laat je dit leeg, dan is dat de naam van je hostingaccount.
• Taal. Alleen bij applicaties die per taal een eigen uitgave publiceren — WordPress doet dat, de meeste andere niet. Staat er niets, dan wordt de applicatie in één taalversie uitgebracht en is er niets te kiezen.

Stap 4 — Bevestigen. Alles wat je gekozen hebt op één scherm, plus wat er gaat gebeuren, in die volgorde: de doelmap wordt gecontroleerd, er wordt een database aangemaakt en de bestanden worden opgehaald, de applicatie wordt ingericht, en gaat het na het uitpakken alsnog mis dan draait de motor het zelf terug. Daarna zie je één keer het wachtwoord van de beheerder. Sla het op — het staat nergens anders, ook niet bij je hostingpartij.

Tot die laatste knop is er niets aangemaakt. Sluit je het venster tussentijds, dan is je account precies zoals het was. Weigert de server de installatie, dan blijft het venster staan met de reden erin en met je antwoorden er nog in, zodat opnieuw proberen één klik is en geen tweede formulier.

Een map waar al een website in staat wordt geweigerd. Er is geen knop om dat te overrulen, en dat is met opzet: een installatie die over een bestaande website heen kan schrijven, doet dat een keer. Wil je toch opnieuw beginnen, leeg dan eerst de map in de bestandsbeheerder, waar verwijderen ook echt is waar het scherm voor bedoeld is.

Als een applicatie hier niet kan draaien

Zodra je een applicatie én een website gekozen hebt, kijkt de server na of het kan — nog op stap 2, dus voordat er iets over de beheerder gevraagd is. Kan het niet, dan staat er een rood blok met de reden en met wat eraan te doen is, en kom je niet voorbij die stap. Kies je een stap terug een andere applicatie, dan verdwijnt de melding en blijft de website die je al koos gewoon staan.

Er zijn drie soorten redenen:

• De PHP-versie van je website. Elke applicatie stelt haar eigen eisen. Joomla 6 start niet onder PHP 8.3; PrestaShop 8.2 weigert juist alles boven 8.1. De melding noemt alleen versies die op deze server echt te kiezen zijn, en je verandert ze op de pagina van de website zelf.
• Een PHP-uitbreiding die ontbreekt. De melding noemt het commando en het scherm waarmee je hem aanzet.
• De plek. Eén applicatie is kieskeurig: een Laravel-applicatie bepaalt aan de hand van het pad in de URL welke pagina je opvraagt, en kan niet verteld worden dat haar eigen pad halverwege begint. Die hoort in de hoofdmap van een website of op een subdomein, niet in een submap.
• Het aantal bestanden dat je account nog mag maken. Dit is de reden die het vaakst verrast, en hij gaat níet over schijfruimte. Deze applicaties zijn bestandsrijk — een MediaWiki brengt ongeveer 34.000 bestanden mee, een Drupal ongeveer 34.000, een Nextcloud ongeveer 30.000 — en een hostingaccount heeft naast een schijflimiet ook een limiet op het aantal bestanden. Loop je daar tegenaan, dan mislukt het uitpakken halverwege en zie je een melding over schijfruimte terwijl je schijf half leeg is. De server telt daarom vooraf. De melding noemt hoeveel bestanden de release meebrengt, hoeveel er nog bij mogen, en wat eraan te doen is: bestanden opruimen die je niet meer nodig hebt, of je beheerder de limiet laten verhogen. Er wordt niets uitgepakt zolang het antwoord "nee" is.

De catalogus, applicatie voor applicatie

Matomo: de laatste drie schermen doe je zelf

Matomo heeft geen installatieprogramma voor de opdrachtregel. Dat is geen keuze van je hostingpartij maar van Matomo zelf: de installatie is een wizard in de browser, en er is geen commando dat een beheerder aanmaakt.

Wat er bij Installeren dus gebeurt: de bestanden worden geplaatst, er wordt een database gemaakt, en je krijgt één keer de gegevens van die database te zien. Ga daarna naar je website, doorloop de drie schermen van Matomo zelf en vul die gegevens in waar Matomo erom vraagt.

Niemand anders kan die wizard voor je afmaken: het eerste scherm vraagt om het databasewachtwoord, en dat heb jij.

Daarna is het een applicatie als alle andere — bijwerken gebeurt met een herstelpunt en met automatisch terugzetten, precies zoals hierboven.

Laravel: geïnstalleerd, niet bijgewerkt

Een Laravel-applicatie is een startpunt waar je zelf op verder bouwt. Vanaf het moment dat hij er staat, leggen de versies van zijn onderdelen vast in je eigen composer.lock — en die verplaats jij, niet je hostingpartij. Nu bijwerken wordt daarom geweigerd met die reden erbij. Herstelpunten en terugzetten werken wél: die gaan over jouw werk, niet over een release.

De website wordt geserveerd uit de map public/. Dat regelt CoreCP met een .htaccess in de hoofdmap, die tegelijk je .env en de mappen van het framework afschermt. Na elke wijziging haalt de server je .env op via het web en keurt de wijziging af als je website hem prijsgeeft — dat bestand bevat je databasewachtwoord en de sleutel waarmee alle sessies ondertekend worden.

MediaWiki: een wiki, zoals Wikipedia er een is

MediaWiki is de software waar Wikipedia op draait, en hij is even goed op zijn plek als handleiding, kennisbank of clubsite. CoreCP installeert hem volledig: de database wordt gemaakt, de wiki wordt ingericht en je krijgt één keer het wachtwoord van de beheerder te zien.

Twee dingen om te weten:

• Je aanmeldnaam begint met een hoofdletter. MediaWiki maakt daar zelf een hoofdletter van, dus heet je account jansen, dan is je wiki-aanmeldnaam Jansen. Het scherm noemt na de installatie de naam die er echt is.
• De kaart toont alleen de versie. MediaWiki heeft geen commando dat vertelt welke uitbreidingen je wiki draait of dat zijn eigen bestanden controleert — dat staat in de wiki zelf, op de pagina Speciaal:Versie. De kaart verzint dat dus niet.

Bijwerken doet CoreCP wel volledig: de bestanden worden vervangen achter een herstelpunt, en daarna draait MediaWiki zijn eigen database-update.

OpenCart: de webshop van de catalogus

Een OpenCart-installatie is meteen een werkende winkel: de database wordt gemaakt, de voorbeeldcatalogus geladen en het beheerscherm staat op /admin/. Ook hier krijg je het beheerderswachtwoord één keer te zien.

Drie dingen om te weten:

• Je wachtwoord is korter dan bij de andere applicaties. OpenCart accepteert hoogstens twintig tekens; CoreCP maakt er dus twintig en toont je precies het wachtwoord dat op de winkel staat.
• Bijwerken blijft binnen één serie. Van 4.1.0.3 naar 4.1.0.4 vervangt CoreCP de bestanden achter een herstelpunt, en dat is precies wat OpenCart voor zo'n update voorschrijft. Een stap naar een volgende serie (4.2) doet OpenCart met zijn eigen wizard in het beheerscherm, onder System → Maintenance → Upgrade, en CoreCP weigert die stap met die verwijzing erbij in plaats van hem half uit te voeren. Wat een bijgewerkte winkel houdt zijn de kolombreedtes waarmee hij ooit is aangemaakt; OpenCart publiceert daar geen migratie voor en CoreCP verzint er geen.
• De map system/storage wordt afgeschermd. Daar staan je sessies, je logboeken, je back-ups en de bestanden die klanten uploaden, en OpenCart zet die map binnen je website. CoreCP sluit hem af, en controleert na elke wijziging via het web dat hij nog steeds dicht zit.
• Je eigen .htaccess blijft staan, ook als de nieuwe versie een andere meebrengt. In dat bestand staat het webadres waarop jouw winkel draait, plus alles wat je er zelf in hebt gezet — dat kan een update niet weten, dus laat CoreCP het met rust. De regels van de nieuwe versie krijg je er wél bij, in het bestand .htaccess.txt naast je eigen bestand. Wil je zien wat er veranderd is, dan zet je die twee naast elkaar; overnemen doe je alleen wat je begrijpt, en er staat altijd een herstelpunt van vóór de update.

PrestaShop: waarom hij er wel staat en niet werkt

PrestaShop 8.2 weigert elke PHP-versie boven 8.1, en dit platform levert 8.3 en nieuwer omdat 8.1 sinds december 2025 geen beveiligingsupdates meer krijgt. PrestaShop 9 wordt niet als los archief gepubliceerd, dus er is niets om te spiegelen. En zijn updates lopen via een module die hij bij zijn eigen marktplaats ophaalt, waar deze server niet bij kan.

Hij staat in de lijst zodat je een reden krijgt in plaats van stilte. Breng je een bestaande PrestaShop mee bij een verhuizing, dan wordt hij wel herkend, gemeten, van herstelpunten voorzien en teruggezet.

Wat er al stond terugvinden

Ben je overgestapt van een andere hostingpartij, of heb je ooit zelf iets geüpload? Klik dan op Zoeken naar installaties. De server kijkt in de hoofdmap van elke website en één map daaronder, herkent wat hij tegenkomt en zet het in de lijst.

Er wordt daarbij niets in je installatie zelf veranderd. "Onder beheer brengen" betekent precies één ding: er komt een regel bij in het overzicht, zodat de rest van deze pagina iets heeft om over te gaan.

Andersom werkt ook: Beheer stoppen haalt die regel weg en laat elk bestand staan waar het staat. De volgende zoekopdracht vindt de installatie gewoon opnieuw.

De kolom "Gemeten", en waarom die er staat

Bij elke installatie staat wanneer er voor het laatst gekeken is, en hoe diep:

• volledig — de applicatie is zelf naar haar versie, haar onderdelen en de toestand van haar bestanden gevraagd. Dat kan WordPress.
• alleen versie — er is alleen de versie van de schijf gelezen. Of er iets nieuwers is, weet de catalogus van je hostingpartij; de applicatie zelf is niets gevraagd.

Dat onderscheid staat er omdat het eerlijk is. Een scherm dat bij elke applicatie "0 updates" zet, zegt bij de helft ervan iets wat niemand heeft nagekeken — en de dag dat dat misgaat is precies de dag dat het uitmaakt.

Met Opnieuw meten haal je de meting nu op in plaats van te wachten tot de server het uit zichzelf doet.

Bijwerken, en wat er gebeurt als het misgaat

Klik een installatie aan en kies Nu bijwerken. Achter die ene knop zitten vier stappen:

1. Er wordt een herstelpunt gemaakt: een kopie van de bestanden én van de database.
2. De update wordt uitgevoerd.
3. De server controleert je site: antwoorden de pagina's nog zoals daarvoor, staat er een nieuwe PHP-fout in je logboek, is de pagina niet ineens half zo groot.
4. Is het antwoord op een van die vragen nee, dan wordt het herstelpunt automatisch teruggezet — bestanden en database.

Je hoeft daar niet bij te zijn en je hoeft er niets voor aan te zetten. In het tabblad Logboek zie je achteraf wat er gebeurd is, welke controle het afkeurde en of er teruggezet is.

Onder Beleid stel je in wat de server uit zichzelf mag bijwerken: niets, alleen beveiligingsupdates (de standaard), of alles. Ook dan geldt de hele lijst hierboven — automatisch bijwerken zonder herstelpunt bestaat hier niet.

Wanneer dat automatische bijwerken gebeurt

Jij kiest wat er automatisch mag; je hostingpartij kiest wanneer. Dat is een venster van een paar nachtelijke uren, apart van het onderhoudsvenster van de server zelf — want dat laatste mag de machine herstarten, en een herstart midden in een database-migratie is precies wat een update nooit tegen moet komen.

Drie dingen doet die nachtelijke ronde niet:

• Bijwerken zonder herstelpunt. Staat dat voor een installatie uitgezet, dan slaat de ronde hem over met die reden erbij.
• Iets aanraken dat er nog niet klaar voor is. Een Matomo waarvan de wizard nooit is afgerond wordt overgeslagen, niet geprobeerd.
• Naar een nieuw hoofdnummer springen. Van Joomla 5 naar Joomla 6 is geen update maar een verhuizing: de database verandert mee en je extensies moeten die stap ook gemaakt hebben. Staat je beleid op beveiligingsupdates, dan gebeurt dat nooit vanzelf. De wachtende uitgave blijft wel op de kaart staan, zodat je hem zelf kunt kiezen wanneer het jou uitkomt.

Als het misgaat hoor je het

Ging een nachtelijke update mis, of is je website erdoor teruggezet naar het herstelpunt, dan staat dat de volgende ochtend op je overzicht én krijg je er bericht over. In dat bericht staat het belangrijkste eerst: je website draait — op de versie van vlak voor de update — en wat er nog openstaat is de update zelf.

Hetzelfde geldt voor een plugin, thema of extensie op een draaiende website die in de lijst met bekende kwetsbaarheden komt te staan. Neemt je beleid beveiligingsupdates, dan wordt dat in het eerstvolgende venster vanzelf dichtgezet en hoef je niets te doen; staat je beleid op "niets", dan blijft het lek open tot iemand het onderdeel bijwerkt of uitzet.

Voor beheerders: het venster van de server zelf

Beheer je de server, dan staat onder de lijst het blok Automatische updates van websites: de schakelaar, het venster, wanneer de eerstvolgende ronde draait, en hoeveel installaties op die machine elk beleid dekken. Dat laatste is er expres bij: wie deze schakelaar omzet mag zien hoe groot het is wat hij aanzet.

Zelf uitproberen of het terugzetten werkt

In het tabblad Overzicht staat Terugdraaien beproeven. Die knop voert de update écht uit en maakt de applicatie daarna expres stuk, zodat de controles hem afkeuren en het herstelpunt teruggezet wordt.

Het is geen simulatie. Je site is een halve minuut stuk en staat er daarna weer, op de versie van vóór de update. Doe het één keer op een rustig moment, dan weet je dat de vangnetten werken voordat je ze nodig hebt.

Een site tijdelijk uit de lucht halen

Soms wil je even geen bezoekers: je importeert drieduizend forumberichten, of je verhuist de productcatalogus van een webshop. De onderhoudsmodus staat op het tabblad Overzicht van een installatie.

Hij gebruikt de schakelaar van de applicatie zélf — Disable board van phpBB, Offline van Joomla, de onderhoudsvlag van WordPress — zodat je applicatie ook wéét dat ze uit de lucht is. Haar eigen beheerscherm zegt het, haar eigen taken staan stil, en er is nergens op het platform een tweede mening over de vraag of je site bezoekers bedient.

Waar de applicatie er plek voor heeft, kun je één regel voor de bezoeker meegeven ("Over een uur weer terug"). Waar dat niet kan, zegt het paneel achteraf welk deel het niet kwijt kon — in plaats van het stilletjes weg te gooien.

Niet elke applicatie heeft zo'n schakelaar. MediaWiki, Matomo, OpenCart en PrestaShop houden die in een instellingenbestand dat alleen jij en hun eigen beheerscherm horen te bewerken, en die van Laravel hoort bij de applicatie die je zelf hebt geschreven. Het scherm zegt dat, in plaats van een knop aan te bieden die zou weigeren.

Weer aanzetten is één knop. Een installatie die uit de lucht is, is in de lijst gemarkeerd en de kop telt ze — zo blijft er niet ongemerkt eentje uit staan als het werk klaar is.

Iets met meerdere tegelijk doen

Vink het hokje vóór een installatie aan en er verschijnt een balk boven de lijst: Bijwerken, Uit de lucht halen, Weer online zetten en Opnieuw meten.

De run geeft een regel per installatie, ook voor de installaties die hij niet gedaan heeft, met de reden erbij. Dat is belangrijker dan het klinkt: een update over vier sites die alleen "klaar" zegt, is niet te onderscheiden van een update die er twee heeft gedaan.

Eén regel houdt de run vol, wat je ook indrukt. Een bulkupdate slaat het herstelpunt nooit over. Staat dat vangnet bij een installatie uit, dan laat de run hem staan en zegt dat erbij — die werk je apart bij, terwijl je ernaar kijkt. De weg terug uitzetten is een besluit over één website, en een knop die er vier tegelijk raakt is daar niet de plek voor.

WordPress-sites staan op allebei de schermen

Een WordPress is een applicatie zoals de andere, dus hij staat ook in deze lijst — met zijn herstelpunten, de geschiedenis van de motor en zijn onderhoudsmodus.

Alles wat specifiek WordPress is — plug-ins, thema's, bekende kwetsbaarheden, de checklist met beveiligingsmaatregelen, de testomgeving — staat op het tabblad WordPress ernaast. Elk scherm heeft een verwijzing naar het andere, dus welke je ook opent: je bent één klik van de rest van het antwoord.

Vanaf de opdrachtregel

Alles hierboven kan ook via SSH, als je hostingpartij je die toegang geeft:

$ corectl app recipes
$ corectl app requirements nextcloud jouwdomein.nl
$ corectl app requirements mediawiki jouwdomein.nl --path wiki
$ corectl app install mediawiki jouwdomein.nl --path wiki \
      --admin-email jij@voorbeeld.nl --title "Onze kennisbank"
$ corectl app install opencart jouwdomein.nl --path winkel \
      --admin-email jij@voorbeeld.nl --title "Onze winkel"
$ corectl app list --account jouwaccount
$ corectl app maintenance phpbb:jouwdomein.nl/forum --state on --message "Over een uur weer terug."
$ corectl app bulk update --account jouwaccount --dry-run on
$ corectl app update phpbb:jouwdomein.nl/forum
$ corectl app snapshots --instance phpbb:jouwdomein.nl/forum
$ corectl app restore phpbb_jouwdomein.nl_forum-20260827T115718Z-s3xa5r \
      --instance phpbb:jouwdomein.nl/forum

Zie ook: Je WordPress-sites voor alles wat er speciaal voor WordPress bijkomt — de beveiligingschecklist, de testomgeving en de kwetsbaarheidsmeldingen.

Waar de applicatiearchieven vandaan komen

De catalogus en elk archief dat het paneel installeert komen van de pakketbron van de server zelf — dezelfde bron waar zijn CoreCP-pakketten vandaan komen, zoals de installer die heeft vastgelegd. Op staging is dat de buildserver, in productie het productiepaneel. Een server zonder vastgelegde bron meldt dat bij het verversen van de catalogus in plaats van stilletjes een testadres te gebruiken.

Op productie: dezelfde catalogus, van je eigen bron

Een productieserver leest de catalogus en de archieven bij zijn eigen pakketbron (het productiepaneel), niet bij de buildserver. Die bron haalt ze ieder uur bij de buildserver op, controleert ze en ondertekent de catalogus opnieuw met zijn werksleutel; een server accepteert die handtekening omdat de hoofdsleutel de werksleutel heeft gecertificeerd — net als bij een pakket. Je merkt er niets van, behalve dat een nieuwe applicatieversie op productie een dag later verschijnt dan op staging: de bron wacht die dag bewust. Zie Releases beheren → De spiegels.

Webmail en phpMyAdmin komen nu uit dezelfde bron

De applicaties die jij installeert komen altijd al uit de eigen spiegel van CoreCP in plaats van zomaar van internet — daar gaat Waar de applicatiearchieven vandaan komen hierboven over. Sinds deze uitgave geldt dat ook voor de twee applicaties die het platform zélf aanbiedt: de webmail op webmail.<jouw domein> en phpMyAdmin.

Je merkt er niets van, en dat is precies de bedoeling. Tot nu haalde je server die twee elke keer rechtstreeks bij de downloadservers van de projecten op, en controleerde niemand wat er binnenkwam. Nu volgen ze dezelfde weg als al het andere hier: een vingerafdruk die één keer is vastgelegd en tegen de eigen handtekening van het project is gecontroleerd, en een bestand dat daar niet aan voldoet wordt niet uitgepakt.

En sinds deze uitgave ook de webserver zelf

Dezelfde spiegel draagt nu één ding dat geen applicatie is: het installatie- archief van LiteSpeed Enterprise, de webserver die op een deel van de servers draait. Het staat er met een eigen soort — leverancier — zodat het nooit in deze catalogus opduikt als iets dat je op een website kunt installeren.

Waarom het er dan wel bij staat: het is dezelfde vraag. Van elk bestand dat op een server terechtkomt moet vastliggen waar het vandaan komt en of het de bytes zijn die we hebben opgeschreven. Een server die de software van zijn websites bij ons haalt en zijn wébserver ergens anders, heeft die regel maar half.

Een map die buiten je home wijst

Maakt de server een map voor je aan in je homedirectory (de datamap van een Nextcloud, of de tijdelijke werkmap van het installatieprogramma), dan volgt hij geen koppeling die buiten je home leidt. Heb je zo'n map vervangen door een koppeling naar een andere plek op de server, dan wordt de handeling geweigerd en staat erbij waarom. Haal de koppeling weg of laat hem binnen je eigen home wijzen, en probeer het opnieuw. Een koppeling die binnen je home blijft, zoals de document root die een import achterlaat, werkt zoals altijd.