Så hostar du ConvertX själv 2026: uppladdningar, JWT-hemligheter och resursgränser

Det finns två versioner av att ”köra ConvertX”: en container existerar, eller så utför tjänsten sitt faktiska arbete. Det är bara det senare som spelar roll. Här är beviset att ladda upp flera representativa format, konvertera vart och ett, ladda ned resultaten och jämföra hashvärden eller medieegenskaper där resultatet är deterministiskt.

ConvertX är avsett för detta: en webbläsarbaserad tjänst för filkonvertering. Driftsättningen måste bevara delarna bakom detta beteende; en port, en volym och ett certifikat är förutsättningar, inte resultatet.

Välj den minsta fungerande ConvertX-topologin

Börja med ConvertX-nätverksnamnrymden: dess webblyssnare använder port 3000, inte en hostport som kopierats från en laptopguide. Kraven på den lokala runtime-miljön är CPU, minne och temporärt diskutrymme som passar de valda konverterarna. Dokumentera förväntad kapacitet, ägarskap och felhantering i stället för att lämna detta åt image-standardvärden.

När kravet är uppfyllt kör du hela scenariot — ladda upp flera representativa format, konvertera vart och ett, ladda ned resultaten och jämför hashvärden eller medieegenskaper där resultatet är deterministiskt. Registrera loggar och mätvärden för CPU, minne, temporärt diskutrymme, filstorlek och de konverterarbinärer som anropas för varje formatpar. Dessa bevis blir den första kända fungerande arkitekturen och gör senare flyttar mellan Dockup compute och en ansluten server testbara.

Håll interna och externa URL:er åtskilda

Undvik tillfälliga och permanenta publika origins för ConvertX. Publicera i stället gränssnittet via HTTPS med medvetet valda uppladdningsgränser, peka det valda DNS-namnet mot plattformsrutten och proxya endast till port 3000.

Testa detta utifrån, utanför hosten: ladda upp flera representativa format, konvertera vart och ett, ladda ned resultaten och jämför hashvärden eller medieegenskaper där resultatet är deterministiskt. Om ingress misslyckas täcker felsökningsguiden för 502 misstag med portar och lyssnare. Om ConvertX tar emot begäran men en konverterarbinär saknas eller proxyn avvisar en stor uppladdning pekar bevisen nu bortom proxyn.

Containerinställningar som är värda att granska

Starta ConvertX på ett sätt som håller rutten privat tills bootstrap är slutförd.

docker run -d \
  --name convertx \
  --restart unless-stopped \
  -p 127.0.0.1:3000:3000 \
  -v convertx-data:/app/data \
  -e JWT_SECRET=replace-with-a-long-random-value \
  ghcr.io/c4illin/convertx:latest

Om processen startar om i en loop jämför du den användare som imagen förväntar sig med ägaren till varje monterad sökväg. Om den fortsätter köras testar du port 3000 lokalt och går sedan direkt vidare till arbetsflödet: ladda upp flera representativa format, konvertera vart och ett, ladda ned resultaten och jämför hashvärden eller medieegenskaper där resultatet är deterministiskt. Lås image-versionen först när denna kontroll från början till slut har godkänts, och dokumentera den exakta konfigurationen intill tjänsten.

Öva på den riskfyllda ConvertX-ändringen

En inaktiv health check säger inte mycket om ConvertX. Bevaka CPU, minne, temporärt diskutrymme, filstorlek och de konverterarbinärer som anropas för varje formatpar. Skapa sedan larm utifrån det symptom användarna upplever: att åtgärden ”ladda upp flera representativa format, konvertera vart och ett, ladda ned resultaten och jämför hashvärden eller medieegenskaper där resultatet är deterministiskt” misslyckas. Håll liveness lokal och billig; låt readiness rapportera migreringar eller initiering utan att orsaka en storm av omstarter.

Det riskfyllda med uppgraderingar är att image-versioner kan lägga till eller ta bort konverterare, så testa den exakta formatmatris som användarna är beroende av. Läs versionsinformationen, skapa en snapshot av tillståndet, driftsätt målversionen mot en återställd kopia och upprepa acceptansåtgärden. Om en konverterarbinär saknas eller proxyn avvisar en stor uppladdning ska du koppla klientbegäran till den första relevanta applikationsloggen i stället för att radera tillstånd eller lägga till omdirigeringar på måfå.

Fem kontroller som är bättre än containerhälsa

Låt inte den första användartrafiken vara acceptanstestet för ConvertX. Förbered ofarligt exempeldata och kör hela åtgärden ”ladda upp flera representativa format, konvertera vart och ett, ladda ned resultaten och jämför hashvärden eller medieegenskaper där resultatet är deterministiskt”. Anteckna den exakta publika URL:en, resultatet, image-referensen och det loggintervall som hör till körningen.

Ersätt containern och upprepa utan att bygga om data. Återställ därefter till en tom host; återställningsvillkoret är att konton och inställningar kommer tillbaka och att den fasta formatmatrisen fortfarande slutförs inom de valda gränserna. Observera CPU, minne, temporärt diskutrymme, filstorlek och de konverterarbinärer som anropas för varje formatpar vid varje körning och definiera ett larm kring försämring av transaktionen i stället för kring inaktiva containermätvärden.

En sista kontroll ska medvetet misslyckas: skicka ofarlig indata nära resurs- eller formatgränsen som hör till denna gräns: en konverterarbinär saknas eller proxyn avvisar en stor uppladdning. Verifiera att det resulterande ConvertX-meddelandet identifierar den relevanta gränsen i stället för att utlösa dataradering eller en oändlig omstart. Återställ det giltiga tillståndet och bekräfta att samma exempeltransaktion lyckas. Behåll denna korta övning i checklistan för releaser.

Hitta varje beständig byte i ConvertX

Den beständiga återställningsmängden består av applikationsdata, konton och eventuella sparade konverteringsinställningar. Montera /app/data före bootstrap, skriv ofarliga exempeldata och ersätt containern för att bevisa att sökvägen faktiskt är beständig. En volym skyddar data från att containern ersätts, men inte från förlust av hosten, oavsiktlig radering eller korruption på applikationsnivå.

Ta säkerhetskopior som förstår datakällan: använd logiska dumpar för aktiva databaser när det krävs och kopiera filer endast från ett konsekvent tillstånd. Förvara en krypterad kopia separat från ConvertX-hosten. Acceptanskriteriet för en återställning är specifikt — konton och inställningar kommer tillbaka och den fasta formatmatrisen fortfarande slutförs inom de valda gränserna. Guiden för återställningstestade säkerhetskopior förklarar varför enbart ett lyckat jobb inte räcker.

Minska den behörighet som ConvertX har

Efter den första inloggningen granskar du vad en anonym besökare, en vanlig användare och en administratör kan göra. Det ConvertX-fel som ska undvikas är att använda ett exempel på en JWT-hemlighet eller att erbjuda obegränsade publika konverteringar. Den avsedda policyn är att använda en riktig JWT-hemlighet, kräva inloggning och begränsa uppladdningar innan opålitliga filer från internet accepteras.

Generera JWT_SECRET som ett långt slumpmässigt värde; en rotation ogiltigförklarar normalt sessioner eller token, så planera användarpåverkan i stället för att kalla det en krypteringsmigrering. Håll konton för beroenden åtskilda från personliga konton, neka oanvänd utgående trafik där det är praktiskt och begränsa arbete som påverkas av CPU, minne, temporärt diskutrymme, filstorlek och de konverterarbinärer som anropas för varje formatpar.

Driftsätt ConvertX på Dockup utan att förlora dess gränser

Dockup eliminerar manuellt arbete med reverse proxy och livscykelhantering runt ConvertX. Tjänsten får en stabil HTTPS-rutt till 3000, injicerad konfiguration och beständig lagring när containrar ersätts. En ansluten kundserver följer samma modell som Dockup-hostad compute.

Efter lanseringen uppfyller du applikationskontraktet: publicera gränssnittet via HTTPS med medvetet valda uppladdningsgränser, bekräfta det lokala kravet — CPU, minne och temporärt diskutrymme som passar de valda konverterarna — och kör detta bevis: ladda upp flera representativa format, konvertera vart och ett, ladda ned resultaten och jämför hashvärden eller medieegenskaper där resultatet är deterministiskt. På så sätt förblir upplevelsen med ett klick användbar utan att detaljerna som gör ConvertX återställningsbart och säkert försvinner.

Vanliga frågor

Vad behöver ConvertX för en produktionsdriftsättning?

Routa ConvertX-containern på port 3000 via en enda HTTPS-origin. Kraven på den lokala runtime-miljön är CPU, minne och temporärt diskutrymme som passar de valda konverterarna. Anse inte ConvertX vara redo förrän du kan ladda upp flera representativa format, konvertera vart och ett, ladda ned resultaten och jämföra hashvärden eller medieegenskaper där resultatet är deterministiskt.

Vilka ConvertX-data ska ingå i en säkerhetskopia?

Gör /app/data beständig och inkludera applikationsdata, konton och eventuella sparade konverteringsinställningar i samma återställningsmanifest. En ren ConvertX-återställning är godkänd först när konton och inställningar kommer tillbaka och den fasta formatmatrisen fortfarande slutförs inom de valda gränserna.

Kräver ConvertX HTTPS bakom en reverse proxy?

Använd HTTPS för den publika ConvertX-originen och behåll port 3000 på den interna rutten. Tillämpa ConvertX-inställningen korrekt: publicera gränssnittet via HTTPS med medvetet valda uppladdningsgränser. För ConvertX skyddar HTTPS autentiseringsuppgifter eller användarinnehåll under överföring och håller klientbeteende som beror på origin konsekvent.

Hur bör en ConvertX-uppgradering testas?

Återställ det aktuella ConvertX-tillståndet i en isolerad driftsättning, tillämpa kandidatversionen och upprepa dess acceptanstransaktion. Var särskilt uppmärksam eftersom image-versioner kan lägga till eller ta bort konverterare, så testa den exakta formatmatris som användarna är beroende av. Behåll den tidigare ConvertX-imagen tills gränserna för datamigrering och rollback är förstådda.