Sådan selvhoster du ConvertX i 2026: uploads, JWT-hemmeligheder og ressourcegrænser

Der findes to versioner af at “køre ConvertX”: Der findes en container, eller også udfører servicen faktisk sit arbejde. Det er kun den anden, der betyder noget. Her er beviset at uploade flere repræsentative formater, konvertere hvert af dem, downloade resultaterne og sammenligne hashes eller medieegenskaber, når resultatet er deterministisk.

ConvertX er beregnet til netop dette: en browserbaseret filkonverteringsservice. Deploymentet skal bevare de dele, der ligger bag denne adfærd; en port, et volume og et certifikat er input, ikke resultatet.

Vælg den mindst mulige ConvertX-topologi, der fungerer

Start med ConvertX' network namespace: dens web listener er port 3000, ikke en host-port kopieret fra en laptop-tutorial. Det lokale runtime-krav er CPU, memory og midlertidig disk, der passer til de valgte converters. Dokumentér den forventede kapacitet, ejerskab og failure mode i stedet for at lade det være en image-default.

Når kravet er opfyldt, skal du køre hele scenariet — uploade flere repræsentative formater, konvertere hvert af dem, downloade resultaterne og sammenligne hashes eller medieegenskaber, når resultatet er deterministisk. Registrér logs og målinger for CPU, memory, midlertidig disk, filstørrelse og de converter binaries, der kaldes for hvert formatpar. Disse data bliver den første kendt-gode arkitektur og gør senere flytninger mellem Dockup compute og en tilknyttet server testbare.

Hold interne og eksterne URL'er adskilt

Undgå midlertidige og permanente offentlige origins til ConvertX. Udgiv i stedet UI'et via HTTPS med bevidste upload-grænser, peg det valgte DNS-navn på platformens route, og proxy kun til port 3000.

Test denne handling udefra hosten: upload flere repræsentative formater, konvertér hvert af dem, download resultaterne og sammenlign hashes eller medieegenskaber, når resultatet er deterministisk. Hvis ingress fejler, gennemgår guiden til fejlfinding af 502 fejl med porte og listeners. Hvis ConvertX modtager requesten, men en converter binary mangler, eller proxyen afviser et stort upload, peger beviserne nu ud over proxyen.

Containerindstillinger, der er værd at gennemgå

Start ConvertX på en måde, der holder routen privat, indtil bootstrap er fuldført.

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

Hvis processen går i loop, skal du sammenligne imagets forventede bruger med ejeren af hver mounted path. Hvis den forbliver kørende, skal du teste port 3000 lokalt og derefter gå direkte videre til workflowet: upload flere repræsentative formater, konvertér hvert af dem, download resultaterne og sammenlign hashes eller medieegenskaber, når resultatet er deterministisk. Version-pin kun imaget, når dette end-to-end-tjek er bestået, og registrér den præcise konfiguration sammen med servicen.

Gennemfør en øvelse med den risikable ConvertX-ændring

Et inaktivt health check siger ikke meget om ConvertX. Overvåg CPU, memory, midlertidig disk, filstørrelse og de converter binaries, der kaldes for hvert formatpar, og alert på det symptom, brugerne oplever: at handlingen “uploade flere repræsentative formater, konvertere hvert af dem, downloade resultaterne og sammenligne hashes eller medieegenskaber, når resultatet er deterministisk” fejler. Hold liveness lokal og billig; lad readiness rapportere migrations eller initialisering uden at udløse en restart storm.

Det risikable område ved upgrades er, at image-releases kan tilføje eller fjerne converters, så test den præcise formatmatrix, som brugerne er afhængige af. Læs release notes, tag et snapshot af state, deploy target-versionen mod en gendannet kopi, og gentag acceptance-handlingen. Hvis en converter binary mangler, eller proxyen afviser et stort upload, skal du sammenholde client requesten med den første relevante application log i stedet for blindt at slette state eller tilføje redirects.

Fem tjek, der er stærkere end container health

Lad ikke trafik fra den første bruger være acceptance-testen for ConvertX. Forbered ufarlig sample state, og kør hele handlingen “uploade flere repræsentative formater, konvertere hvert af dem, downloade resultaterne og sammenligne hashes eller medieegenskaber, når resultatet er deterministisk”. Notér den præcise offentlige URL, resultatet, image-reference og det log-interval, der er knyttet til kørslen.

Erstat containeren, og gentag uden at genopbygge data. Gendan derefter på en tom host; recovery-betingelsen er, at konti og settings kommer tilbage, og at den faste formatmatrix stadig gennemføres inden for de valgte grænser. Observer CPU, memory, midlertidig disk, filstørrelse og de converter binaries, der kaldes for hvert formatpar, i hver gennemgang, og definér en alert omkring forringelse af transaktionen i stedet for omkring metrics fra en inaktiv container.

Et sidste tjek skal fejle med vilje: indsend ufarligt input tæt på den ressource- eller formatgrænse, der er knyttet til denne grænse: en converter binary mangler, eller proxyen afviser et stort upload. Kontrollér, at den resulterende ConvertX-meddelelse identificerer den relevante grænse i stedet for at udløse sletning af data eller en endeløs restart. Gendan den gyldige tilstand, og bekræft, at den samme sample-transaktion lykkes. Behold denne korte øvelse i release-checklisten.

Find alle persistente bytes i ConvertX

Det persistente recovery-sæt er application data, konti og eventuelle gemte conversion settings. Mount /app/data før bootstrap, skriv ufarlige sample data, og erstat containeren for at bevise, at stien faktisk er persistent. Et volume beskytter data mod udskiftning af containeren, men ikke mod tab af hosten, utilsigtet sletning eller korruption på applikationsniveau.

Tag backups, der forstår datakilden: brug logical dumps til live databases, når det er nødvendigt, og kopiér kun filer fra en konsistent tilstand. Opbevar én krypteret kopi væk fra ConvertX-hosten. Acceptance-kriteriet for en restore er specifikt — konti og settings kommer tilbage, og den faste formatmatrix gennemføres stadig inden for de valgte grænser. Guiden til restore-testede backups forklarer, hvorfor et job, der lykkes, ikke er tilstrækkeligt i sig selv.

Begræns de rettigheder, ConvertX har

Efter det første login skal du gennemgå, hvad en anonym besøgende, en almindelig bruger og en administrator hver især kan gøre. Den ConvertX-fejl, du skal undgå, er at bruge et eksempel på en JWT-secret eller tilbyde ubegrænsede offentlige konverteringer. Den tilsigtede policy er at bruge en rigtig JWT-secret, kræve login og begrænse uploads, før du accepterer filer fra internettet, som du ikke stoler på.

Generér JWT_SECRET som en lang, tilfældig værdi; en rotation ugyldiggør normalt sessions eller tokens, så planlæg brugerens påvirkning i stedet for at kalde det en encryption migration. Hold dependency-konti adskilt fra menneskelige konti, afvis unødvendig egress, hvor det er praktisk, og begræns arbejde, der påvirkes af CPU, memory, midlertidig disk, filstørrelse og de converter binaries, der kaldes for hvert formatpar.

Deploy ConvertX på Dockup uden at miste dets grænser

Dockup fjerner manuelt reverse-proxy- og lifecycle-arbejde omkring ConvertX. Servicen får en stabil HTTPS-route til 3000, injected configuration og persistent storage under udskiftninger. En tilknyttet kundeserver følger samme model som Dockup-hosted compute.

Efter launch skal du opfylde applikationskontrakten: udgiv UI'et via HTTPS med bevidste upload-grænser, bekræft det lokale krav — CPU, memory og midlertidig disk, der passer til de valgte converters — og kør dette bevis: upload flere repræsentative formater, konvertér hvert af dem, download resultaterne og sammenlign hashes eller medieegenskaber, når resultatet er deterministisk. Det holder one-click-oplevelsen nyttig uden at udviske de detaljer, der gør ConvertX gendanneligt og sikkert.

Ofte stillede spørgsmål

Hvad kræver ConvertX til et production-deployment?

Route ConvertX-containeren på port 3000 gennem én HTTPS-origin. Det lokale runtime-krav er CPU, memory og midlertidig disk, der passer til de valgte converters. Kald ikke ConvertX klar, før du kan uploade flere repræsentative formater, konvertere hvert af dem, downloade resultaterne og sammenligne hashes eller medieegenskaber, når resultatet er deterministisk.

Hvilke ConvertX-data hører hjemme i en backup?

Persistér /app/data, og inkludér application data, konti og eventuelle gemte conversion settings i det samme recovery-manifest. En ren ConvertX-restore er kun bestået, når konti og settings kommer tilbage, og den faste formatmatrix stadig gennemføres inden for de valgte grænser.

Kræver ConvertX HTTPS bag en reverse proxy?

Brug HTTPS til den offentlige ConvertX-origin, og hold port 3000 på den interne route. Anvend ConvertX-indstillingen korrekt: udgiv UI'et via HTTPS med bevidste upload-grænser. For ConvertX beskytter HTTPS credentials eller brugerindhold under transport og holder origin-følsom client-adfærd konsistent.

Hvordan skal en ConvertX-upgrade testes?

Gendan den aktuelle ConvertX-state i et isoleret deployment, anvend candidate-versionen, og gentag dens acceptance-transaktion. Vær særligt opmærksom, fordi image-releases kan tilføje eller fjerne converters, så test den præcise formatmatrix, som brugerne er afhængige af. Behold det tidligere ConvertX-image, indtil dets data-migration og rollback-grænse er forstået.