How to Self-Host IT Tools in 2026: TLS, Stateless Deploys and Updates

Self-hosting IT Tools becomes interesting at the first redeploy, not the first docker run. If the proxy targets the wrong container port or caches an old application shell, Docker can still report a perfectly healthy process. The deployment below is organized around observable behavior: load the interface, generate a hash, decode a JWT and use one converter with the browser network disconnected after assets are cached.

The intended job of IT Tools is explicit: collection of hashes, converters, generators and developer utilities. That description tells us what must stay public, what should remain private and what a backup has to reconstruct.

Separate IT Tools from its dependencies

Start with the IT Tools network namespace: its web listener is port 80, not a host port copied from a laptop tutorial. The standard IT Tools build needs no database or separate persistent runtime service. Keep the web container replaceable and put any future authentication, collaboration or storage component behind a separately documented boundary.

After the requirement is satisfied, run the complete scenario — load the interface, generate a hash, decode a JWT and use one converter with the browser network disconnected after assets are cached. Record logs and measurements for client browser memory, static asset delivery and the absence of server-side database or queue work. That evidence becomes the first known-good architecture and makes later moves between Dockup compute and an attached server testable.

Build a replaceable IT Tools container

A minimal command is useful when it reveals what the platform will later manage.

docker run -d \
  --name it-tools \
  --restart unless-stopped \
  -p 127.0.0.1:80:80 \
  corentinth/it-tools:latest

Here port 80 remains host-private and every required path is explicit. Confirm the local requirement before exposure: no database; only a small web container. Verify startup with both logs and the application-specific proof: load the interface, generate a hash, decode a JWT and use one converter with the browser network disconnected after assets are cached. Once verified, lock the image version so a routine replacement does not silently change behavior.

TLS is easy; generated URLs are not

The public boundary for IT Tools should be one canonical hostname, automatic TLS and one internal target on 80. Route the static web application through HTTPS so clients return to an address the service recognizes.

If the acceptance transaction fails, classify the first error. DNS, certificate and 502 problems belong to the TLS validation checklist. The condition “the proxy targets the wrong container port or caches an old application shell” belongs to the application side after a request has successfully reached IT Tools.

Volumes are only the first recovery layer

Recovery for stateless IT Tools is a reproducibility exercise. Preserve no server data; keep the deployment configuration; the writable container layer should contain nothing needed after replacement.

Use the pinned image and reviewed configuration to rebuild IT Tools on blank compute. The drill passes when a fresh container reproduces the same tool set because there is no server-side user state to recover. Follow the Git-to-production deployment workflow for the replaceable artifact, while any optional external service keeps a separate backup procedure.

Document the exact digest and acceptance input. This lets an operator distinguish an application regression from missing state and avoids attaching a ceremonial volume that IT Tools never reads.

Close temporary setup access

Security for stateless IT Tools starts with supply-chain and ingress controls, not a fictional account setting. Avoid assuming browser-side tools make pasted secrets safe on an untrusted host. The intended boundary is to serve a trusted upstream image and remind users that self-hosting does not make a compromised browser trustworthy.

Serve IT Tools from a trusted pinned image, add platform authentication if the audience is private and expose only port 80 through HTTPS. Set resource and request limits around client browser memory, static asset delivery and the absence of server-side database or queue work. Because no built-in secret exists in this baseline, keep access policy in the route configuration and test it from an unauthorized client.

Rehearse the risky IT Tools change

Monitor behavior, not merely the process: load the interface, generate a hash, decode a JWT and use one converter with the browser network disconnected after assets are cached. The surrounding pressure signals are client browser memory, static asset delivery and the absence of server-side database or queue work. Run that check after startup and on a schedule that cannot overload the service.

An update can be promoted only after testing that an image update can change client-side algorithms or dependencies, so pin and verify the build that handles sensitive input. Use a parallel candidate, pinned digests and known inputs; this base image has no schema migration to rehearse. If the proxy targets the wrong container port or caches an old application shell, compare the two versions before altering ingress or adding storage.

Record a known-good IT Tools deployment

Do not make first-user traffic the acceptance test for IT Tools. Prepare harmless sample state and run the complete action “load the interface, generate a hash, decode a JWT and use one converter with the browser network disconnected after assets are cached”. 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 a fresh container reproduces the same tool set because there is no server-side user state to recover. Observe client browser memory, static asset delivery and the absence of server-side database or queue work 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: the proxy targets the wrong container port or caches an old application shell. Verify that the resulting IT Tools 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.

A Dockup deployment still needs an IT Tools acceptance test

Dockup can deploy the pinned IT Tools image to Dockup compute or a server the customer attaches, route the public hostname to port 80 and issue TLS automatically. The standard container has no application database, so Dockup should not attach a meaningless data volume merely to imitate a stateful template.

After deployment, route the static web application through HTTPS. Dockup should preserve the IT Tools runtime settings while the operator confirms this local requirement: no database; only a small web container. Run the known-output check: load the interface, generate a hash, decode a JWT and use one converter with the browser network disconnected after assets are cached. If custom fonts, authentication, collaboration or configuration are added later, declare those components and their state explicitly instead of folding them into the stateless web image. This keeps one-click deployment honest about what Dockup manages and what IT Tools itself actually stores.

Frequently asked questions

What does IT Tools need for a production deployment?

Route the IT Tools container on port 80 through one HTTPS origin. The standard IT Tools build needs no database or separate persistent runtime service. Do not call IT Tools ready until you can load the interface, generate a hash, decode a JWT and use one converter with the browser network disconnected after assets are cached.

Which IT Tools data belongs in a backup?

The standard IT Tools image has no required application-data mount. Preserve its deployment configuration and back up any connected state separately; recovery passes when a fresh container reproduces the same tool set because there is no server-side user state to recover.

Does IT Tools require HTTPS behind a reverse proxy?

Use HTTPS for the public IT Tools origin and keep port 80 on the internal route. Apply the IT Tools setting correctly: route the static web application through HTTPS. For IT Tools, HTTPS protects credentials or user content in transit and keeps origin-sensitive client behavior consistent.

How should an IT Tools upgrade be tested?

Deploy the candidate IT Tools image beside the current one and repeat the acceptance transaction with known input. Pay particular attention because an image update can change client-side algorithms or dependencies, so pin and verify the build that handles sensitive input. The standard container has no data migration, so retain the previous digest until output and compatibility checks pass.