How to Self-Host ConvertX in 2026: Uploads, JWT Secrets and Resource Limits

There are two versions of “running ConvertX”: a container exists, or the service completes its real job. Only the second matters. Here the proof is to upload several representative formats, convert each, download the results and compare hashes or media properties where deterministic.

ConvertX serves this purpose: browser-based file conversion service. The deployment has to preserve the pieces behind that behavior; a port, a volume and a certificate are inputs, not the result.

Choose the smallest viable ConvertX topology

Start with the ConvertX network namespace: its web listener is port 3000, not a host port copied from a laptop tutorial. The local runtime requirement is CPU, memory and temporary disk suited to the selected converters. Document the expected capacity, ownership and failure mode rather than leaving it as an image default.

After the requirement is satisfied, run the complete scenario — upload several representative formats, convert each, download the results and compare hashes or media properties where deterministic. Record logs and measurements for CPU, memory, temporary disk, file size and the converter binaries invoked by each format pair. That evidence becomes the first known-good architecture and makes later moves between Dockup compute and an attached server testable.

Keep internal and external URLs straight

Avoid temporary and permanent public origins for ConvertX. Instead, publish the UI through HTTPS with deliberate upload limits, point the chosen DNS name at the platform route and proxy only to port 3000.

Exercise this action from outside the host: upload several representative formats, convert each, download the results and compare hashes or media properties where deterministic. If ingress fails, the 502 troubleshooting guide covers port and listener mistakes. If ConvertX receives the request but a converter binary is missing or the proxy rejects a large upload, the evidence now points beyond the proxy.

Container settings worth reviewing

Start ConvertX in a way that leaves the route private until bootstrap is complete.

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

If the process loops, compare the image's expected user with the owner of each mounted path. If it stays up, test port 3000 locally and then move directly to the workflow: upload several representative formats, convert each, download the results and compare hashes or media properties where deterministic. Version-pin the image only after that end-to-end check passes, and record the exact configuration beside the service.

Rehearse the risky ConvertX change

An idle health check says little about ConvertX. Watch CPU, memory, temporary disk, file size and the converter binaries invoked by each format pair, then alert on the symptom users experience: failure of the action “upload several representative formats, convert each, download the results and compare hashes or media properties where deterministic”. Keep liveness local and cheap; let readiness report migrations or initialization without causing a restart storm.

The risky upgrade area is that image releases can add or remove converters, so test the exact format matrix users depend on. Read release notes, snapshot state, deploy the target version against a restored copy and repeat the acceptance action. If a converter binary is missing or the proxy rejects a large upload, correlate the client request with the first relevant application log rather than deleting state or adding redirects blindly.

Five checks stronger than container health

Do not make first-user traffic the acceptance test for ConvertX. Prepare harmless sample state and run the complete action “upload several representative formats, convert each, download the results and compare hashes or media properties where deterministic”. Note the exact public URL, result, image reference and log interval associated with the run.

Replace the container and repeat without rebuilding data. Next, recover onto an empty host; the recovery condition is that accounts and settings return and the fixed format matrix still completes within chosen limits. Observe CPU, memory, temporary disk, file size and the converter binaries invoked by each format pair in every pass and define an alert around degradation of the transaction rather than around idle container metrics.

One final check should fail on purpose: submit harmless input near the resource or format limit associated with this boundary: a converter binary is missing or the proxy rejects a large upload. Verify that the resulting ConvertX message identifies the relevant boundary instead of triggering data deletion or an endless restart. Restore the valid condition and confirm the same sample transaction succeeds. Keep this short drill in the release checklist.

Find every durable byte in ConvertX

The durable recovery set is application data, accounts and any retained conversion settings. Mount /app/data before bootstrap, write harmless sample data and replace the container to prove that path is actually persistent. A volume protects data from container replacement, but not from host loss, accidental deletion or application-level corruption.

Take backups that understand the data source: use logical dumps for live databases when required and copy files only from a consistent state. Keep one encrypted copy away from the ConvertX host. The acceptance criterion for a restore is specific — accounts and settings return and the fixed format matrix still completes within chosen limits. The restore-tested backup guide explains why job success alone is insufficient.

Reduce the authority held by ConvertX

After first login, review what an anonymous visitor, ordinary user and administrator can each do. The ConvertX failure to avoid is using an example JWT secret or offering unrestricted public conversions. The intended policy is to use a real JWT secret, require login and cap uploads before accepting untrusted files from the internet.

Generate JWT_SECRET as a long random value; rotating it normally invalidates sessions or tokens, so plan the user impact rather than calling it an encryption migration. Keep dependency accounts separate from human accounts, deny unused egress where practical and cap work influenced by CPU, memory, temporary disk, file size and the converter binaries invoked by each format pair.

Deploy ConvertX on Dockup without losing its boundaries

Dockup removes manual reverse-proxy and lifecycle work around ConvertX. The service receives a stable HTTPS route to 3000, injected configuration and persistent storage during replacements. An attached customer server follows the same model as Dockup-hosted compute.

After launch, satisfy the application contract: publish the UI through HTTPS with deliberate upload limits, confirm the local requirement — CPU, memory and temporary disk suited to the selected converters and run this proof: upload several representative formats, convert each, download the results and compare hashes or media properties where deterministic. This keeps the one-click experience useful without flattening the details that make ConvertX recoverable and secure.

Frequently asked questions

What does ConvertX need for a production deployment?

Route the ConvertX container on port 3000 through one HTTPS origin. The local runtime requirement is CPU, memory and temporary disk suited to the selected converters. Do not call ConvertX ready until you can upload several representative formats, convert each, download the results and compare hashes or media properties where deterministic.

Which ConvertX data belongs in a backup?

Persist /app/data and include application data, accounts and any retained conversion settings in the same recovery manifest. A clean ConvertX restore passes only when accounts and settings return and the fixed format matrix still completes within chosen limits.

Does ConvertX require HTTPS behind a reverse proxy?

Use HTTPS for the public ConvertX origin and keep port 3000 on the internal route. Apply the ConvertX setting correctly: publish the UI through HTTPS with deliberate upload limits. For ConvertX, HTTPS protects credentials or user content in transit and keeps origin-sensitive client behavior consistent.

How should a ConvertX upgrade be tested?

Restore current ConvertX state into an isolated deployment, apply the candidate version and repeat its acceptance transaction. Pay particular attention because image releases can add or remove converters, so test the exact format matrix users depend on. Keep the previous ConvertX image until its data-migration and rollback boundary are understood.