Plesk Obsidian-uppdatering: Nya funktioner för webbhotellsleverantörer

Skillnaden mellan versionsstatus och komponenter ska vara tydlig

Den dokumenterade situationen per den 2 oktober 2026 är följande för Huvudprodukt Plesk Obsidian 18.0.81 Uppdatering 2. Denna uppdatering släpptes den 29 september 2026 och åtgärdar ett kritiskt säkerhetsproblem. De nya panel-funktionerna som beskrivs i den här artikeln ingår i versionen Plesk Obsidian 18.0.81 från den 15 september 2026; uppdatering 1 och uppdatering 2 innehåller däremot dokumenterade fel- och säkerhetskorrigeringar.

Det kan dock finnas senare uppdateringar som inte påverkar kärnversionen 18.0.81 Update 2: I ändringsloggen anges till exempel uppdateringar för tillägg som SSL It! och Let’s Encrypt från den 29 september samt uppdateringar av PHP-paket från den 30 september 2026. Den som endast talar om en „aktuell Plesk“-version utelämnar därför viktig information för planering och support.

Plesk skiljer mellan flera uppdateringsnivåer. Plesk-paketen utgör själva kontrollpanelen och dess direkt tillhörande funktioner. Utöver detta finns servicepaket och tillägg som tillhandahålls av Plesk och som ger ytterligare funktioner eller kan ansluta till externa tjänster. Ett nytt versionsnummer för ett tillägg är därför inget bevis på att även Plesk-kärnan är uppdaterad – och tvärtom.

Dessutom driver varje Webbhotellspanel Inom ett operativsystem finns ytterligare nivåer: operativsystempaket samt komponenter från tredje part, till exempel databaser, PHP-runtidsmiljöer, webbservrar och e-posttjänster. Deras paketkällor, supportcykler och beroenden följer inte nödvändigtvis Plesks utgivningsrytm. För en leverantör är denna uppdelning praktiskt relevant, eftersom felbilder, underhållsfönster och ansvarsområden kan variera beroende på vilken komponent som berörs.

I inventariedokumentationen bör därför alltid den konkreta kombinationen anges: Plesk-version med uppdateringsnummer, version av installerade tillägg, operativsystem och relevanta runtime-paket. När det gäller certifikat- eller applikationsfunktioner ingår även den använda integrationen. På så sätt går det att spåra om en ändring härrör från SSL It!, en Let’s Encrypt-integration eller från panelens kärna. Detta förhindrar otydliga förväntningar vid kundmeddelanden och underlättar felsökningen inom supporten.

Hur Plesk-uppdateringar påverkar leverantörer

Inom Obsidian-serien 18.0 släpps uppdateringar löpande och sekventiellt installerad. Enskilda mellanliggande uppdateringar kan inte hoppas över. Detta skapar en definierad uppdateringsväg, men befriar inte en leverantör från att kontrollera sin egen miljö: Ju fler kundwebbplatser, individuella PHP-beroenden och tillägg en server hanterar, desto viktigare är frågan om vilken ändring som påverkar vilken tjänsteklass.

Plesk beskriver automatiska uppdateringar för egna uppdateringar samt separata alternativ för medföljande tredjepartskomponenter och systempaket. Dokumentationssidan ger dock motstridiga uppgifter om standardinställningen för alternativet för tredjepartskomponenter. Administratörer bör därför inte utgå från en globalt gällande standardinställning, utan kontrollera de faktiskt inställda alternativen för varje server under Tools & Settings > Update Settings Kontrollera. Man bör i synnerhet vara försiktig, eftersom nyare komponenter kan vara inkompatibla med webbplatser som ligger på en webbserver.

För driften av många kundinstanser är denna åtskillnad en fördel när den omsätts i praktiken. Panelkorrigeringar och säkerhetsändringar kan planeras utifrån deras omfattning; komponentbyten får däremot en egen kompatibilitetsbedömning. Ett managed hosting-erbjudande behöver inte omedelbart införliva varje tillgänglig paketversion. Det avgörande är vilka versioner som passar den utlovade stacken, den testade kundbasen och den planerade supportmodellen.

Fördelarna med de senaste Obsidian-versionerna fördelar sig på flera verksamhetsområden: diagnostikfunktioner kan strukturera förstahandssupporten, nya verktyg för applikationshosting utökar prisalternativen, och certifikat- samt assistansfunktioner berör säkerhet och behörighetshantering. Artikeln behandlar även tidigare grunder och utvecklingar inom produktlinjen Plesk Obsidian 2025: Revolutionerande innovationer för webbhotell . För den aktuella lanseringen är det dock den exakta komponenten som är avgörande, inte enbart produktnamnet.

Automatisering är alltså inte ett generellt godkännandebeslut. Det är klokt att göra en åtskillnad mellan regelbunden installation av dokumenterade Plesk-uppdateringar och medvetet styrda ändringar i kundstacken. Särskilt när det gäller delade servrar skyddar denna gräns mot att ett obemärkt komponentbyte samtidigt påverkar många webbplatser som är oberoende av varandra. Den ersätter inte tester, men gör riskerna synliga och identifierbara.

Nya funktioner efter hosting-scenario

Inom delad hosting är ett första användningsområde att snabbare kunna identifiera domänstörningar. De i Plesk Obsidian 18.0.81 Allmänt tillgänglig DNS-diagnos sammanfattar kontroller av upplösning, MX-relaterade aspekter, DNSSEC, namnservrar och domänens giltighetstid. Den överskådliga rapporten i panelen kan hjälpa supportmedarbetare att på ett strukturerat sätt undersöka problem relaterade till DNS, e-post och delegering innan de eskaleras.

Rapporten är dock en Diagnos och ingen automatisk korrigering. I synnerhet domänalias är för närvarande inte omfattade. Även om ett felmeddelande pekar på en felaktig delegering eller zon kan det i vissa fall vara registratorn eller en extern DNS-operatör som ansvarar för att åtgärda felet. Som supportverktyg är funktionen därför särskilt användbar om ansvarsområden och nästa eskaleringssteg tydligt anges i supportärendet.

Ett andra område är Applikationshosting för byråer och utvecklare. Node.js Toolkit 2.5.0 kompletteras med en central översikt över aktiverade Node.js-applikationer och konfiguration av befintliga projekt med ett enda klick. Den automatiska igenkänningen kan identifiera flera vanliga serverramverk samt statiska frontend-lösningar. Dessutom stöder tillägget pnpm uteslutande under Plesk för Linux. Detta minskar återkommande enskilda steg, men innebär inte någon garanti för att varje enskild distribution kan överföras oförändrad.

Den nya Python-tillägget 1.0.0 är även avsett för Linux-system och erbjuder Python-stöd per domän, virtuella miljöer, beroenden, miljövariabler och krypterat lagrade hemligheter. Applikationerna körs som WSGI-applikationer via Phusion Passenger; behörigheten „Python support management“ kan styras via serviceplaner och prenumerationer. Detta kan bli en kontrollerad prisplanfunktion, men är inte automatiskt en ersättning för alla Python-arkitekturer.

Ett tredje område omfattar certifikat och assistansfunktioner. I version 18.0.81 stöder SSL It! DNS-validering som ett alternativ till HTTP-validering för de nämnda ext-acme- och ext-letsencrypt-integrationerna. Detta är till exempel relevant för domäner utan öppen port 80. En förutsättning är fortfarande att det finns ett lämpligt sätt att lägga in DNS-poster i den faktiskt ansvariga zonen; enbart visningen av en post ger inte skrivbehörighet.

MCP är som standard inaktiverat i version 18.0.81 och kan kopplas till via ett WebPros-konto. Administratörer anger i panel.ini de användartyper som får ansluta MCP-klienter. Dess lämplighet beror därför inte bara på funktionen, utan även på roller, behörigheter och loggning. Plattformsberoende utökade funktioner, extern DNS-hantering och arkitekturen för klientapplikationen avgör sammantaget vilken ny funktion som hör hemma i vilken prisplan.

Funktionsjämförelse för produktplanering

När det gäller produktplaneringen räcker det inte med beteckningen Plesk Obsidian: De funktioner som är relevanta här härrör dels från kärnprodukten, dels från tillägg som versioneras separat. Därför bör en leverantör inte utvärdera funktioner enbart utifrån deras nytta, utan i stället ta med operativsystem, licensmodell och tekniska beroenden i prislistan.

Översikten gör en särskilt tydlig åtskillnad mellan en plattformsfunktion och en marknadsförbar tjänst. DNS-diagnosen kan i stor utsträckning fungera som ett supportverktyg. Python ingår däremot endast i Linux-erbjudanden där rättighetshanteringen och supportgränserna är anpassade för detta. När det gäller Node.js måste leverantören skilja mellan de olika delfunktionerna: pnpm är enligt dokumentationen exklusivt för Linux, medan ändringsloggen inte innehåller motsvarande begränsningar för den centrala översikten och autokonfigurationen.

Även certifikat- och MCP-funktionerna kräver ett produktval istället för en global aktivering. I DNS-01 avgör behörigheten för zonen den praktiska användbarheten. När det gäller MCP är den tekniska anslutningen bara en del av projektet; avgörande är vilka personer som har behörighet, spårbara processer och hanteringen av åtgärder med sidoeffekter.

DNS-diagnos och certifikat i supporten

Den allmänna versionen av Plesk Obsidian 18.0.81 DNS-diagnos är lämpligt som en första teknisk bedömning av ett domänärende. I panelen öppnar „Troubleshoot DNS“ en överskådlig rapport om DNS-upplösning, MX-relaterade kontroller, DNSSEC, namnserverproblem och domänens utgångsdatum. Detta förkortar den inledande kontrollen, men ersätter varken analysen av den auktoritativa zonen eller samordningen med registratorn eller en extern DNS-operatör.

För att säkerställa en repeterbar process på första nivån bör supporten först registrera den berörda huvuddomänen och rapporten, och därefter fastställa ansvar och hur allvarligt problemet är. Om rapporten till exempel visar på en felaktig delegering ligger ofta åtgärden utanför panelens ansvarsområde. Det är också viktigt att notera den dokumenterade begränsningen: domänalias omfattas för närvarande inte av denna kontroll.

För diagnostik via kommandoraden beskriver ändringsloggen följande kommando med en neutral exempeldomän. Innan kommandot används bör en administratör kontrollera hjälpen eller kommandodokumentationen för den faktiskt installerade versionen av Plesk. Enbart utifrån den syntax som anges i ändringsloggen går det inte att dra några ytterligare slutsatser om kommandots samtliga effekter.

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

Utökad information om certifikat DNS-01-validering Det möjliga användningsområdet: SSL It! kan användas i Plesk Obsidian 18.0.81 som ett alternativ till HTTP-validering vid utfärdande och förnyelse. Detta är till exempel relevant för API- eller e-postdomäner där port 80 medvetet inte är öppen. Plesk visar de nödvändiga DNS-posterna och sparar den valda metoden per domän för senare förlängningar.

Processen genomförs dock inte automatiskt bara för att en post visas. Operatören behöver skrivbehörighet till den faktiskt berörda DNS-zonen eller en lämpligt konfigurerad automatiseringsväg. Den DNS-validering som infördes med version 18.0.81 gäller enligt ändringsloggen endast för SSL It!-integrationerna ext-acme och ext-letsencrypt, inte generellt för alla certifikatleverantörer.

Detta skiljer sig från den senare utökninguppdateringen SSL It! 1.24.0 från den 29 september 2026. Med denna version kan en domän utan webbhotell säkras med ett wildcard-certifikat via kontrollpanelen eller kommandoraden; den automatiska förlängningen sker också som ett wildcard-certifikat. Denna tilläggsfunktion ingår inte i den ursprungliga funktionsomfattningen för Plesk Obsidian 18.0.81, utan följer tilläggets egen versions- och publiceringsstatus.

Applikationshosting som ett reglerat prisalternativ

Med de senaste tilläggen blir applikationshosting lättare att avgränsa som ett prisalternativ. Node.js Toolkit 2.5.0 kompletteras med en central översikt över aktiverade Node.js-applikationer och en konfiguration av befintliga projekt med ett enda klick. Dessutom stöder tillägget pakethanteraren pnpm i Plesk för Linux. På så sätt kan en leverantör standardisera återkommande installationsuppgifter utan att behöva hantera varje kundapplikation som en enskild serverdrift.

Enligt ändringsloggen omfattar projektigenkänningen bland annat Express, Next.js, NestJS och Nuxt.js samt statiska frontend-lösningar baserade på React, Vue.js, Angular eller Vite. Plesk kan skapa en Passenger-kompatibel startfil, ta hänsyn till hårdkodade portar och ställa in dokumentroten, varvid ändringarna visas innan de bekräftas. Statiska frontend-miljöer byggs och levereras utan en permanent körande Node.js-process.

Denna automatisering är användbar, men ersätter inte en arkitekturgranskning. Flera processer, arbetsköer, särskilda omvända proxyservrar, externa hemligheter eller egna byggpipelines kan kräva ytterligare driftsregler. Enligt ändringsloggen gäller Linux-begränsningen uttryckligen för pnpm; för den centrala domänöversikten och autokonfigurationen med ett klick anges ingen motsvarande plattformsbegränsning där. Beskrivningarna av prisplanerna bör därför nämna dessa delfunktioner separat.

Python-tillägget 1.0.0 erbjuder på Linux en separat styrbar miljö per domän. Kunderna kan skapa virtuella miljöer, installera beroenden via gränssnittet, visa metadata från pyproject.toml samt hantera miljövariabler och krypterat lagrade hemligheter. Tillgången aktiveras via behörigheten „Python support management“ i serviceplaner och abonnemang.

Tekniskt sett körs dessa applikationer som WSGI-applikationer via Phusion Passenger; Plesk skapar webbserverkonfigurationen automatiskt. Ett „Python Web App“-abonnemang kan därför till exempel innehålla virtuella miljöer, en definierad resursram och support för klassiska WSGI-projekt. Detta innebär dock inte att samma abonnemang täcker komplexa ASGI-stackar, kontinuerligt körande arbetare eller specialarkitekturer i containrar.

För att sätta in äldre funktioner och gränssnittsändringar i sitt sammanhang kan artikeln Plesk Obsidian: En översikt över nyheter och förbättringar kan användas som komplement. För nya tariffer är det fortfarande avgörande att gemensamt dokumentera utvidgningsversionen, dokumenterade plattformsgränser, behörigheter och den specifika typ av applikation som stöds.

Införa uppdateringar stegvis i produktionen

En uppdatering av webbhotellspanelen bör inte påbörjas i en leverantörsmiljö redan vid det första klicket på den produktiva huvudservern. Skapa först en Inventarieförteckning av Plesk-versioner, operativsystemversioner, aktiverade tillägg och de kundapplikationer som körs på dem. Dessutom är externa beroenden viktiga, såsom DNS-leverantörer, e-postreläer, säkerhetskopior, egna PHP-paket och driftsättningsprocesser. På så sätt blir det tydligt vilka system som har samma version och vilka specialfall som måste hanteras separat.

Kontrollera därefter beroendena för varje serverklass. En uppdatering av en kärnprodukt kan få andra konsekvenser än en uppdatering av ett tillägg eller en tredjepartskomponent. Även de paket som tillhandahålls av operativsystemet utgör ett separat underhållsområde. Plesk skiljer uttryckligen mellan dessa kategorier; särskilt uppdateringar av tredjepartskomponenter kan påverka webbplatser om dessa inte är förberedda för ändrade versioner eller körmiljöer.

Därefter rekommenderas en representativ Pilotinstans istället för en godtycklig testserver. Den bör återspegla typiska abonnemangskonstellationer: till exempel klassiska CMS-webbplatser, e-postdomäner, databasanvändning samt aktiverade Node.js- eller Python-applikationer, om sådana erbjuds. Syftet är inte att simulera fullständig likhet med produktionsmiljön, utan att i förväg synliggöra relevanta kombinationer av operativsystem, tillägg och kundapplikationer.

Fastställ ett underhållsfönster med en tydlig ordningsföljd för den produktiva driftsättningen. Uppdatera först en begränsad servergrupp, utvärdera resultaten och utvidga sedan driftsättningen. Kontrollera därefter panelens tillgänglighet, planerade säkerhetskopieringar, webb- och e-posttjänster, certifikatförnyelser samt felmeddelanden från de berörda applikationerna. Dessa kontroller minskar osäkerheten, men utgör ingen garanti för avbrottsfri drift eller fullständig applikationskompatibilitet.

När det gäller kapacitetsplanering anger Plesk minimikrav på 1 GB RAM plus 1 GB swap under Linux och 2 GB RAM under Windows. För delad hosting anges som en grov rekommendation 1 GB RAM per 40 till 50 webbplatser, förutsatt att högst tio procent av alla webbplatser som hostas har ett ihållande eller regelbundet antal besökare per vecka eller månad. Sådana Riktvärden för resurser utgör ingen kapacitetsgaranti och ersätter inte en mätning av den egna belastningen: databasaktivitet, e-postvolym, säkerhetsprogramvara och typ av applikation kan påverka behovet avsevärt.

Identifiera felkällor och säkerhetsprioriteringar

Återkommande fel beror oftast på otydliga produktgränser. Dokumentera därför den specifika versionen av kärnprodukten eller tillägget vid varje tillkännagivande. En Node.js- eller Python-funktion får inte generellt marknadsföras för Windows-paket om den endast är dokumenterad för Plesk för Linux. På samma sätt är Python-hosting med WSGI via Passenger inte detsamma som att godkänna valfria ASGI-, Worker- eller containerarkitekturer.

• Planera in DNS-01 som en tariffegenskap först när skrivåtkomst till den auktoritativa DNS-zonen eller en lämplig automatiseringsväg finns tillgänglig.
• Jämför inte alternativen för automatiska uppdateringar av Plesk, tredjepartskomponenter och systempaket; kontrollera den faktiska inställningen för varje server under „Verktyg och inställningar > Uppdateringsinställningar“.
• Kontrollera tillägg, behörigheter och operativsystem innan nya funktioner aktiveras för varje produktlinje.
• För MCP: Ange tillåtna användargrupper, godkännandeprocesser och loggning av åtgärder innan en roll godkänns.

Die Säkerhetsprioritet beror inte enbart på underhållsfönstrets lämplighet. Vid artikelns publicering är Plesk Obsidian 18.0.81 Update 2 från den 29 september 2026 den aktuella dokumenterade patchversionen för denna kärnversionsserie; Plesk påpekar att det finns ett kritiskt säkerhetsproblem och rekommenderar att uppdateringen installeras så snart som möjligt. Uppdatering 1 från den 21 september innehöll också en kritisk säkerhetskorrigering, som uttryckligen anges gälla Linux i ändringsloggen. För Linux-system bör man därför inte stanna kvar vid uppdatering 1.

I ändringsloggen listas dessutom kritiska säkerhetskorrigeringar för Node.js Toolkit 2.5.0 från den 14 september 2026 och Site Import 1.12.2 från den 23 september 2026. Kontrollera därför alltid om den berörda komponenten är installerad och behandla Panel-kärnan, tillägg, PHP-paket och övriga tillägg som separata uppdateringsvägar. En senare uppdatering av ett tillägg eller PHP ersätter inte en utestående uppdatering av kärnprodukten.

MCP förtjänar en begränsad Testdrift istället för en omedelbar, omfattande aktivering. Funktionen är inaktiverad som standard; administratörer kan i panel.ini Fastställ vilka användartyper som får ansluta MCP-klienter. Bestäm i förväg vilka uppgifter som ska stödjas, vem som får granska ändringar och hur misstänkta eller oönskade åtgärder ska spåras. En AI-integration ersätter varken rollmodeller, förändringshantering eller tekniska granskningar.

Varning: Tredjepartskomponenter bör inte installeras okontrollerat i alla kundmiljöer enbart på grund av att en nyare version finns tillgänglig. Plesk påpekar att det kan förekomma inkompatibiliteter med webbplatser som hostas; samtidigt innehåller den aktuella dokumentationssidan motstridiga uppgifter om huruvida den aktuella automatiska funktionen är aktiverad som standard. Kontrollera därför för varje server under Tools & Settings > Update Settings de valda alternativen och planera för en stegvis lansering av vanliga löptider och plugins med en representativ pilotgrupp.

Välj mellan uppgradering eller serverflytt

Valet mellan Uppgradering på plats och serveröverföringen utgår från det aktuella läget, inte från den önskade Obsidian-versionen. En uppgradering på samma server förutsätter att operativsystemet och den installerade ursprungliga Plesk-versionen stöds för den planerade uppgraderingsvägen. Kontrollera dessutom vilka tillägg som används, eventuella egna anpassningar och det tillgängliga utrymmet för säkerhetskopior. Att en uppdateringsväg är tekniskt möjlig innebär inte nödvändigtvis att den är lämplig för alla kundmiljöer.

I uppgraderingsdokumentationen för Plesk Onyx anges direkta vägar till Obsidian för versionerna 17.0, 17.5 och 17.8. Äldre eller icke-kompatibla utgångsmiljöer kan kräva en överföring till en ny Obsidian-server, förutsatt att utgångsversionen går att migrera. Överföringen gör det möjligt att förbereda operativsystem, resurslayout och tillägg separat från det gamla systemet.

Det är särskilt viktigt att utvärdera en ny målserver om det befintliga operativsystemet närmar sig slutet av sin supportperiod, om plattformen har anpassats individuellt under en längre tid eller om flera stora versionshopp sammanfaller. Systemkraven för Plesk utgör i detta sammanhang endast den lägsta gränsen för planeringen. För målstorleken räknas även antalet webbplatser, e-postkonton, databaser, säkerhetstjänster, lagringsutrymme för säkerhetskopior och den förväntade belastningen efter migreringen.

På Uppgradering genom överföring flyttas den befintliga miljön till en server där Plesk Obsidian är installerat. Enligt uppgraderingsdokumentationen är det en förutsättning att målserverns operativsystem stöds och att den installerade ursprungsversionen tillåter en migrering till Obsidian. Om denna metod är tillgänglig bör därför kontrolleras utifrån den konkreta källversionen innan planeringen påbörjas.

För att säkerställa en aktuell, stödd och överskådlig installation är det oftast det mest självklara valet att snabbt installera uppdateringar efter inventering och pilotprojekt. Vid nya utökningar eller Linux-specifika funktioner är det lämpligt att genomföra en målinriktad pilotfas. Om operativsystemets stöd, utgångsversionen eller tekniska arv begränsar möjligheterna bör man först Förberedelser inför migreringen . Vilken variant som är lämplig avgörs av supportstatus, kompatibilitet och driftsmodell – inte av ett generellt godkännande för produktionsanvändning.