Plesk Obsidian-opdatering: Nye funktioner til hostingudbydere

Sørg for en klar adskillelse mellem versionsstatus og komponenter

Den dokumenterede status pr. 2. oktober 2026 er for Hovedprodukt Plesk Obsidian 18.0.81 Update 2. Denne opdatering blev udgivet den 29. september 2026 og løser et kritisk sikkerhedsproblem. De nye panel-funktioner, der beskrives i denne artikel, er en del af udgivelsen Plesk Obsidian 18.0.81 fra den 15. september 2026; opdatering 1 og opdatering 2 indeholder derimod dokumenterede fejl- og sikkerhedsrettelser.

Der kan dog forekomme senere opdateringer, uden at kernestatus 18.0.81 Update 2 ændres: Changeloggen indeholder for eksempel opdateringer til udvidelser som SSL It! og Let’s Encrypt fra den 29. september samt opdateringer til PHP-pakker fra den 30. september 2026. Den, der blot taler om en „aktuel Plesk“, udelader derfor en oplysning, der er vigtig for planlægning og support.

Plesk skelner mellem flere opdateringsniveauer. Plesk-pakker udgør selve kontrolpanelet og de funktioner, der er direkte knyttet hertil. Derudover findes der servicepakker og udvidelser, som Plesk stiller til rådighed, og som kan tilføre yderligere funktioner eller integrere eksterne tjenester. Et nyt versionsnummer for en udvidelse er derfor ikke et tegn på, at Plesk-kernen også er opdateret – og omvendt.

Derudover driver hver Hosting-panel Inden for et operativsystem findes der yderligere niveauer: operativsystempakker samt tredjepartskomponenter, såsom databaser, PHP-runtime-miljøer, webservere og e-mailtjenester. Deres pakkekilder, supportcyklusser og afhængigheder følger ikke nødvendigvis Plesks udgivelsesrytme. For en udbyder er denne opdeling praktisk relevant, da fejlmønstre, vedligeholdelsesvinduer og ansvarsområder kan variere afhængigt af den berørte komponent.

I statusdokumentationen bør der derfor altid angives den konkrete kombination: Plesk-version med opdateringsnummer, version af installerede udvidelser, operativsystem og relevante runtime-pakker. Ved certifikat- eller applikationsfunktioner skal den anvendte integration også angives. På den måde kan man f.eks. spore, om en ændring stammer fra SSL It!, en Let’s Encrypt-integration eller fra Panel-kernen. Dette forhindrer uklare forventninger i forbindelse med kundemeddelelser og gør det nemmere at indkredse problemet i supporten.

Hvordan Plesk-opdateringer påvirker udbydere

Inden for Obsidian-serien 18.0 udgives der løbende opdateringer, og sekventielt installeret. Enkelte mellemliggende opdateringer kan ikke springes over. Dette skaber en fastlagt opdateringsvej, men fritager ikke en udbyder for at kontrollere sit eget miljø: Jo flere kundewebsteder, individuelle PHP-afhængigheder og udvidelser en server indeholder, desto vigtigere er det at afklare, hvilke ændringer der påvirker hvilke serviceklasser.

Plesk beskriver automatiske opdateringer for egne opdateringer samt separate indstillinger for medfølgende tredjepartskomponenter og systempakker. Dokumentationssiden giver dog modstridende oplysninger om standardindstillingen for tredjepartskomponenter. Administratorer bør derfor ikke gå ud fra en globalt gældende standardindstilling, men i stedet kontrollere de faktisk indstillede indstillinger for hver enkelt server under Tools & Settings > Update Settings Kontroller. Der skal udvises særlig forsigtighed, da nyere komponenter kan være uforenelige med hostede hjemmesider.

For driften af mange kundeinstanser er denne skelnen en fordel, når den omsættes til konkrete processer. Panelrettelser og sikkerhedsændringer kan planlægges ud fra deres omfang, mens udskiftning af komponenter derimod underkastes en særskilt kompatibilitetsvurdering. Et managed hosting-tilbud behøver ikke straks at indføre hver eneste tilgængelige pakkeversion. Det afgørende er, hvilke versioner der passer til den aftalte stack, den testede kundebase og den planlagte supportmodel.

Fordelene ved de nyere Obsidian-versioner fordeler sig på flere driftsområder: Diagnosefunktioner kan strukturere first-level-supporten, nye værktøjer til applikationshosting udvider prisplanmulighederne, og certifikat- samt supportfunktioner vedrører sikkerhed og rettighedsstyring. Artiklen gennemgår også tidligere grundlag og udviklinger i produktlinjen Plesk Obsidian 2025: Revolutionerende nyskabelser til webhosting . For den aktuelle lancering er det dog den konkrete komponent, der er afgørende, og ikke alene produktnavnet.

Automatisering er altså ikke en generel godkendelsesbeslutning. Det er fornuftigt at skelne mellem regelmæssig installation af dokumenterede Plesk-opdateringer og bevidst styrede ændringer i kundestakken. Især på delte servere forhindrer denne afgrænsning, at en ubemærket komponentændring påvirker mange indbyrdes uafhængige hjemmesider på én gang. Den erstatter ikke test, men gør risici synlige og identificerbare.

Nye funktioner efter hosting-scenarie

Inden for shared hosting er et af de første anvendelsesområder hurtigere lokalisering af domænefejl. De i Plesk Obsidian 18.0.81 Generelt tilgængelig DNS-diagnose samler tjek vedrørende opløsning, MX-relaterede aspekter, DNSSEC, navneservere og domænets udløb. Den overskuelige rapport i panelet kan hjælpe supportmedarbejdere med at gennemgå DNS-, e-mail- og delegeringsspørgsmål på en struktureret måde, inden sagen eskaleres.

Rapporten er dog en Diagnose og ingen automatisk korrektion. Især domænealiaser er i øjeblikket ikke omfattet. Selv hvis en fejlmelding peger på en fejlbehæftet delegering eller zone, ligger ansvaret for afhjælpningen i nogle tilfælde hos registratoren eller en ekstern DNS-udbyder. Som supportværktøj er funktionen derfor særligt nyttig, når ansvarsforhold og det næste eskaleringstrin er klart angivet i supportanmodningen.

Et andet område er Applikationshosting til bureauer og udviklere. Node.js Toolkit 2.5.0 tilføjer et centralt overblik over aktiverede Node.js-applikationer samt konfiguration af eksisterende projekter med et enkelt klik. Den automatiske genkendelse kan registrere flere udbredte server-frameworks samt statiske frontends. Derudover understøtter udvidelsen pnpm udelukkende under Plesk til Linux. Dette reducerer gentagne enkelttrin, men er ikke en garanti for, at hver enkelt implementering kan overføres uændret.

Den nye Python-udvidelse 1.0.0 er også rettet mod Linux-systemer og tilbyder Python-understøttelse pr. domæne, virtuelle miljøer, afhængigheder, miljøvariabler og krypteret lagring af hemmelige oplysninger. Applikationerne kører som WSGI-applikationer via Phusion Passenger; rettigheden „Python support management“ kan styres via serviceplaner og abonnementer. Dette kan blive en kontrolleret prisfunktion, men er ikke automatisk en erstatning for enhver Python-arkitektur.

Et tredje område omfatter certifikater og hjælpefunktioner. SSL It! understøtter i version 18.0.81 DNS-validering som et alternativ til HTTP-validering for de nævnte ext-acme- og ext-letsencrypt-integrationer. Dette er f.eks. relevant for domæner uden en åben port 80. Forudsætningen er stadig, at der findes en passende måde at oprette DNS-poster i den faktisk ansvarlige zone; den blotte visning af en post giver ikke skriveadgang.

MCP er som standard deaktiveret i version 18.0.81 og kan tilknyttes via en WebPros-konto. Administratorer angiver i panel.ini de brugertyper, der må oprette forbindelse til MCP-klienter. Dens egnethed afhænger derfor ikke kun af funktionen, men også af roller, tilladelser og logning. Platformsafhængige udvidelsesfunktioner, ekstern DNS-ansvar og arkitekturen i klientapplikationen er samlet set afgørende for, hvilken nyhed der hører hjemme i hvilket prisabonnement.

Funktionssammenligning til produktplanlægning

I forbindelse med produktplanlægningen er betegnelsen »Plesk Obsidian« ikke tilstrækkelig: De relevante funktioner stammer dels fra kerneproduktet, dels fra udvidelser, der versioneres separat. Derfor bør en udbyder ikke kun vurdere funktionerne ud fra deres nytteværdi, men også medtage operativsystem, udgivelsesmodel og tekniske afhængigheder i prislisten.

Oversigten skelner særligt tydeligt mellem en platformfunktion og en markedsførbar tjeneste. DNS-diagnosen kan i bred forstand fungere som et supportværktøj. Python hører derimod kun hjemme i Linux-tilbud, hvor rettighedsstyringen og supportgrænserne er indrettet hertil. Hvad angår Node.js, skal udbyderen skelne mellem de respektive delfunktioner: pnpm er dokumenteret som eksklusivt til Linux, mens changeloggen ikke indeholder tilsvarende begrænsninger for den centrale oversigt og autokonfigurationen.

Også certifikat- og MCP-funktionerne kræver en produktbeslutning i stedet for en global aktivering. I DNS-01 er det ansvarsfordelingen for zonen, der afgør den praktiske anvendelighed. I forbindelse med MCP er den tekniske forbindelse kun en del af projektet; det afgørende er den tilladte personkreds, gennemsigtige processer og håndteringen af handlinger med bivirkninger.

DNS-diagnose og certifikater i supporten

Den generelt tilgængelige version i Plesk Obsidian 18.0.81 DNS-diagnose er velegnet som en første teknisk vurdering af en domænesag. I panelet åbner „Troubleshoot DNS“ en overskuelig rapport om DNS-opløsning, MX-relaterede kontroller, DNSSEC, navneserverproblemer og domænets udløbsdato. Dette forkorter den indledende kontrol, men erstatter hverken analysen af den autoritative zone eller afstemningen med registratoren eller en ekstern DNS-udbyder.

For at sikre en standardiseret procedure på første niveau bør supporten først registrere det berørte hoveddomæne og rapporten og derefter fastlægge ansvarsområdet og alvorligheden. Hvis rapporten f.eks. viser en fejlagtig delegering, ligger løsningen ofte uden for panelets ansvarsområde. Det er også vigtigt at være opmærksom på den dokumenterede begrænsning: Domænealiaser er i øjeblikket ikke omfattet af denne kontrol.

Til diagnosticering fra kommandolinjen beskriver changeloggen følgende kommando med et neutralt eksempeldomæne. Inden anvendelse bør en administrator kontrollere hjælpen eller kommandodokumentationen for den faktisk installerede Plesk-version. Ud fra den syntaks, der er angivet i changeloggen, kan der ikke udledes nogen yderligere garanti for alle kommandoens konsekvenser.

plesk repair dns -n -j -check-resolution example.com

Udvidet for certifikater DNS-01-validering Det mulige anvendelsesområde: SSL It! kan bruges i Plesk Obsidian 18.0.81 som et alternativ til HTTP-validering ved udstedelse og fornyelse. Dette er f.eks. relevant for API- eller e-mail-domæner, hvor port 80 bevidst ikke er åben. Plesk viser de nødvendige DNS-poster og gemmer den valgte metode for hvert domæne til senere fornyelser.

Processen gennemføres dog ikke automatisk, blot fordi der vises en post. Operatøren skal have skriveadgang til den faktisk relevante DNS-zone eller en passende automatiseringsløsning. Den DNS-validering, der blev indført med version 18.0.81, gælder ifølge changeloggen kun for SSL It!-integrationerne ext-acme og ext-letsencrypt, ikke generelt for alle certifikatudbydere.

Den senere udvidelsesopdatering er adskilt herfra SSL It! 1.24.0 fra den 29. september 2026. Med denne version kan et domæne uden hosting sikres med et wildcard-certifikat via kontrolpanelet eller kommandolinjen; den automatiske fornyelse sker ligeledes som et wildcard-certifikat. Denne tilføjelse er ikke en del af den oprindelige funktionsomfang i Plesk Obsidian 18.0.81, men følger udvidelsens egen versions- og udgivelsesstatus.

Applikationshosting som en kontrolleret prisplan

Med de seneste udvidelser er det blevet lettere at afgrænse applikationshosting som en prisplan. Node.js Toolkit 2.5.0 tilføjer en samlet oversigt over aktiverede Node.js-applikationer samt en konfiguration af eksisterende projekter med et enkelt klik. Derudover understøtter udvidelsen pakkehåndteringen pnpm under Plesk til Linux. Dermed kan en udbyder standardisere tilbagevendende opsætningsopgaver uden at skulle behandle hver enkelt kundeapplikation som en individuel serverdrift.

Ifølge changeloggen omfatter projektgenkendelsen blandt andet Express, Next.js, NestJS og Nuxt.js samt statiske frontends baseret på React, Vue.js, Angular eller Vite. Plesk kan oprette en Passenger-kompatibel startfil, tage højde for hardkodede porte og indstille dokumentroden, hvor ændringerne vises før bekræftelse. Statiske frontends kompileres og leveres uden en permanent kørende Node.js-proces.

Denne automatisering er nyttig, men kan ikke erstatte en arkitekturvurdering. Flere processer, worker-køer, særlige reverse-proxyer, eksterne hemmeligheder eller egne build-pipelines kan kræve yderligere driftsregler. Ifølge changeloggen gælder Linux-begrænsningen udtrykkeligt for pnpm; for den centrale domæneoversigt og autokonfigurationen med ét klik er der ikke angivet nogen tilsvarende platformbegrænsning. Tarifbeskrivelser bør derfor angive disse delfunktioner separat.

Python-udvidelsen 1.0.0 introducerer på Linux en separat styrbar løsning pr. domæne. Kunderne kan oprette virtuelle miljøer, installere afhængigheder via brugergrænsefladen, se metadata fra pyproject.toml og administrere miljøvariabler samt krypteret gemte hemmeligheder. Aktivering sker via rettigheden „Python support management“ i serviceplaner og abonnementer.

Teknisk set kører disse applikationer som WSGI-applikationer via Phusion Passenger; Plesk opretter automatisk webserverkonfigurationen. Et „Python Web App“-abonnement kan derfor f.eks. omfatte virtuelle miljøer, en defineret ressourceramme og support til klassiske WSGI-projekter. Det betyder dog ikke, at det samme abonnement dækker komplekse ASGI-stacks, permanent kørende workere eller containerbaserede specialarkitekturer.

Artiklen kan bruges til at sætte ældre funktioner og ændringer i brugergrænsefladen i perspektiv Plesk Obsidian: Oversigt over nye funktioner og forbedringer kan anvendes som supplement. For nye takster er det afgørende, at udvidelsesversionen, de dokumenterede platformgrænser, tilladelser og den konkret understøttede applikationstype dokumenteres i fællesskab.

Indføre opdateringer gradvist i produktionen

En opdatering af hostingpanelet bør i et udbydermiljø ikke starte ved det første klik på den produktive hovedserver. Opret først en Inventar bestående af Plesk-versioner, operativsystemversioner, aktiverede udvidelser og de kundeapplikationer, der kører på dem. Desuden er eksterne afhængigheder vigtige, såsom DNS-udbydere, mail-relays, backups, egne PHP-pakker og implementeringsprocesser. På denne måde bliver det tydeligt, hvilke systemer der har samme status, og hvilke særlige tilfælde der skal behandles separat.

Kontroller derefter afhængighederne for hver serverklasse. En opdatering af et kerneprodukt kan have andre konsekvenser end en opdatering af en udvidelse eller en tredjepartskomponent. Også de pakker, der stilles til rådighed af operativsystemet, udgør et særskilt vedligeholdelsesområde. Plesk adskiller disse kategorier udtrykkeligt; især opdateringer af tredjepartskomponenter kan påvirke hjemmesider, hvis disse ikke er forberedt på ændrede versioner eller kørselsmiljøer.

Dernæst anbefales det at gennemføre en repræsentativ Pilotinstans i stedet for en vilkårlig testserver. Den bør afspejle typiske abonnementsopsætninger: f.eks. klassiske CMS-websteder, e-mail-domæner, databasebrug samt aktiverede Node.js- eller Python-applikationer, hvis disse tilbydes. Formålet er ikke at simulere fuldstændig identitet med produktionsmiljøet, men at synliggøre relevante kombinationer af operativsystem, udvidelser og kundeapplikationer på forhånd.

Fastlæg et vedligeholdelsesvindue med en klar rækkefølge til den produktive udrulning. Opdater først en begrænset gruppe af servere, vurder resultaterne, og udvid først derefter udrulningen. Kontroller derefter panelets tilgængelighed, planlagte sikkerhedskopieringer, web- og e-mailtjenester, certifikatfornyelser samt fejlmeddelelser fra de berørte applikationer. Disse kontroller mindsker usikkerheden, men er ikke en garanti for, at der ikke opstår nedbrud eller for fuldstændig applikationskompatibilitet.

Med hensyn til kapacitetsplanlægning angiver Plesk minimumsværdier på 1 GB RAM plus 1 GB swap under Linux og 2 GB RAM under Windows. For delt hosting angives en grov anbefaling på 1 GB RAM pr. 40 til 50 hjemmesider, forudsat at højst ti procent af alle hostede hjemmesider har et vedvarende eller regelmæssigt antal besøgende pr. uge eller måned. Sådanne Vejledende ressourceværdier udgør ingen kapacitetsgaranti og erstatter ikke en måling af den egne belastning: Aktivitet i databasen, e-mail-trafik, sikkerhedssoftware og applikationstype kan ændre behovet betydeligt.

At identificere fejlkilder og sikkerhedsprioriteter

Tilbagevendende fejl skyldes oftest uklare produktgrænser. Dokumenter derfor den konkrete kerneprodukt- eller udvidelsesversion ved hver annoncering. En Node.js- eller Python-funktion må ikke generelt markedsføres til Windows-abonnementer, hvis den kun er dokumenteret til Plesk for Linux. Ligeledes er Python-hosting med WSGI via Passenger ikke det samme som en godkendelse af vilkårlige ASGI-, worker- eller containerarkitekturer.

• DNS-01 bør først planlægges som en takstfunktion, hvis der er skriveadgang til den autoritative DNS-zone eller en passende automatiseringsvej.
• Indstillingerne for automatiske opdateringer af Plesk, tredjepartskomponenter og systempakker skal ikke sidestilles; kontroller den faktisk indstillede tilstand for hver server under „Tools & Settings > Update Settings“.
• Kontroller udvidelser, rettigheder og operativsystemer, inden nye funktioner aktiveres for hver produktlinje.
• For MCP skal man inden en rollefrigivelse definere tilladte brugergrupper, frigivelsesveje og logning af handlinger.

Die Sikkerhedsprioritet afhænger ikke udelukkende af, hvor praktisk vedligeholdelsesvinduet er. På artiklens udgivelsesdato er Plesk Obsidian 18.0.81 Update 2 fra den 29. september 2026 den aktuelle dokumenterede patch-status for denne kerneudgivelseslinje; Plesk påpeger i den forbindelse et kritisk sikkerhedsproblem og anbefaler, at opdateringen installeres hurtigst muligt. Update 1 fra den 21. september indeholdt ligeledes en kritisk sikkerhedsrettelse, som udtrykkeligt er angivet under Linux i changeloggen. For Linux-systemer bør man derfor ikke forblive på Update 1.

Changeloggen indeholder desuden i september kritiske sikkerhedsrettelser til Node.js Toolkit 2.5.0 fra den 14. september 2026 og Site Import 1.12.2 fra den 23. september 2026. Kontroller derfor altid, om den pågældende komponent er installeret, og behandl Panel-kernen, udvidelser, PHP-pakker og andre tilføjelser som separate opdateringsstier. En senere opdatering af en udvidelse eller PHP erstatter ikke en udestående opdatering af kerneproduktet.

MCP fortjener en begrænset Prøvedrift i stedet for en øjeblikkelig, bred aktivering. Funktionen er som standard deaktiveret; administratorer kan i panel.ini Fastlæg, hvilke brugertyper der må oprette forbindelse til MCP-klienter. Fastlæg på forhånd, hvilke opgaver der skal understøttes, hvem der må godkende ændringer, og hvordan mistænkelige eller uønskede handlinger skal spores. En AI-integration erstatter hverken rollemodeller, ændringsstyring eller tekniske gennemgange.

Advarsel: Tredjepartskomponenter bør ikke installeres ukontrolleret i alle kundemiljøer alene på grund af, at der findes en nyere version. Plesk gør opmærksom på mulige inkompatibiliteter med hostede hjemmesider; samtidig indeholder den aktuelle dokumentationsside modstridende oplysninger om, hvorvidt den pågældende automatiske funktion er aktiveret som standard. Kontroller derfor for hver server under Tools & Settings > Update Settings de valgte indstillinger og planlæg en trinvis implementering af almindelige kørselstider og plugins med en repræsentativ pilotgruppe.

Vælg mellem opgradering eller serveroverførsel

Valget mellem Opgradering på stedet og serveroverførslen starter med den aktuelle tilstand, ikke med den ønskede Obsidian-version. En opgradering på samme server forudsætter, at operativsystemet og den installerede udgangsversion af Plesk understøtter den planlagte opgraderingsvej. Kontroller desuden de anvendte udvidelser, egne tilpasninger og den tilgængelige plads til sikkerhedskopier. At en opdateringsvej er teknisk mulig, betyder ikke nødvendigvis, at den er egnet til alle kundemiljøer.

I opgraderingsvejledningen til Plesk Onyx angives direkte opgraderingsveje til Obsidian for versionerne 17.0, 17.5 og 17.8. Ældre eller ikke-understøttede udgangsmiljøer kan gøre det nødvendigt at overføre data til en ny Obsidian-server, forudsat at udgangsversionen kan migreres. Overførslen giver mulighed for at forberede operativsystem, ressourceopbygning og udvidelser separat fra det gamle system.

Det er især værd at undersøge en ny målserver, hvis det eksisterende operativsystem nærmer sig slutningen af sin supportperiode, hvis platformen er blevet tilpasset individuelt over en længere periode, eller hvis der er flere store versionsskift på samme tid. Systemkravene fra Plesk udgør i denne sammenhæng kun den nedre grænse for planlægningen. Ved fastsættelsen af målstørrelsen skal der ligeledes tages højde for antallet af hjemmesider, e-mailkonti, databaser, sikkerhedstjenester, backupopbevaring og den forventede belastning efter migreringen.

På Opgradering via overførsel flyttes det eksisterende miljø til en server, hvor Plesk Obsidian er installeret. Ifølge opgraderingsvejledningen er det en forudsætning, at målserverens operativsystem understøttes, og at den installerede udgangsversion tillader en migrering til Obsidian. Det bør derfor kontrolleres ud fra den konkrete kildeversion, om denne metode er tilgængelig, inden planlægningen påbegyndes.

For at sikre en opdateret, understøttet og overskuelig installation er det som regel den mest oplagte løsning at installere opdateringer hurtigt efter opgørelse og pilotprojekt. Ved nye udvidelser eller Linux-specifikke tilbudsfunktioner er en målrettet pilotfase fornuftig. Hvis operativsystemsupport, udgangsversion eller tekniske arvelaster begrænser mulighederne, bør man først Forberedt til migration . Hvilken variant der er egnet, afhænger af supportstatus, kompatibilitet og driftsmodel – ikke af en generel produktionsgodkendelse.