How to Self-Host CyberChef in 2026: Secure Access, Stateless Hosting and Updates

The shortest CyberChef demo proves that a process listens on port 80. Production needs stronger evidence. It must pass this scenario even after the container has been replaced: build a multi-step recipe, export it, process a representative file and confirm the output hash matches a known value.

CyberChef is being deployed for a clear purpose: browser workbench for encoding, decoding, parsing and cryptography. Its most common deployment trap is that large operations exhaust browser memory even though the server is healthy, so public URL handling and durable state receive the same attention as image startup.

Choose the smallest viable CyberChef topology

A useful CyberChef diagram shows the public route, private port 80, state boundary and every supporting requirement. Mark which arrows carry credentials and which are ordinary user traffic. The standard CyberChef 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.

Prove the diagram with one real action: build a multi-step recipe, export it, process a representative file and confirm the output hash matches a known value. The likely pressure comes from browser memory and CPU for large recipes rather than container-side compute in the standard static deployment; monitor that path rather than treating all HTTP requests as equal.

Run the first production-shaped instance

Use the container as a replaceable runtime, not as the location of truth.

docker run -d \
  --name cyberchef \
  --restart unless-stopped \
  -p 127.0.0.1:80:80 \
  ghcr.io/gchq/cyberchef:latest

Confirm the local requirement before exposure: no database for the standard client-side build. Inspect the container user, writable paths and bound listener before exposing it. Run the complete action — build a multi-step recipe, export it, process a representative file and confirm the output hash matches a known value — and save the exact image reference that produced the result.

Test CyberChef from outside the server

Publish the static interface on a trusted HTTPS origin. Send the chosen hostname to container port 80, forward the original host and HTTPS scheme, and avoid publishing a second direct origin.

Test CyberChef from a clean external client. Separate ingress failure from the known application boundary — large operations exhaust browser memory even though the server is healthy. A certificate, DNS or 502 error belongs to routing; a request that reaches CyberChef and fails later belongs to application state, capacity or its supporting requirement. The custom-domain TLS guide covers the first group.

Find every durable byte in CyberChef

The standard CyberChef container has no required application-data mount. Its recovery set is still explicit: no application data; preserve deployment configuration and image pin. Do not create an empty volume merely to make the deployment look stateful; preserve the exact image reference and reviewed configuration instead.

Rebuild CyberChef on a blank host and run the acceptance transaction. Recovery passes when the pinned static build can be recreated and an exported recipe produces the same known output. Any connected database or collaboration service follows its own application-consistent backup plan, while the replaceable web container is recreated from code. The Git-to-production deployment guide describes that reproducible boundary.

Keep a checksum or digest for the known-good image and retest after updates. For a stateless service, a successful rebuild is the restore test; for external state, the CyberChef runbook must link to the separate owner and recovery procedure.

Protect the valuable part of CyberChef

Do not add a fake environment secret merely to make CyberChef look hardened. The meaningful concern is processing sensitive material in a modified or untrusted image, so publish only an official or reproducibly built image when operators will paste credentials, captures or encoded evidence.

Restrict the public route when required, verify the image digest and run the container without host mounts or privileges it does not need. Apply limits based on browser memory and CPU for large recipes rather than container-side compute in the standard static deployment. Logs should record failures and timings without retaining sensitive input processed by CyberChef.

Diagnose a healthy-looking CyberChef

Measure browser memory and CPU for large recipes rather than container-side compute in the standard static deployment while running this regression transaction: build a multi-step recipe, export it, process a representative file and confirm the output hash matches a known value. Keep the liveness probe cheap; conversion or browser-side work belongs in a separate release check so a heavy sample cannot trigger a restart loop.

The upgrade risk is that CyberChef recipe operations and bundled libraries can change output or compatibility, so the pinned build needs a regression test. Run the candidate digest beside the current image, feed both the same known inputs and compare outputs, headers and timing. If large operations exhaust browser memory even though the server is healthy, preserve the failed request and image reference before changing the route.

Turn the CyberChef smoke test into a release check

The release record for CyberChef needs facts, not “looks good.” Store the selected image digest, configuration checksum, public hostname and a timestamped result for: build a multi-step recipe, export it, process a representative file and confirm the output hash matches a known value. Use non-production sample data so the check can run after every deployment.

Prove two lifecycle events separately. A container replacement must preserve normal operation; a clean recovery must show that the pinned static build can be recreated and an exported recipe produces the same known output. While the checks run, measure browser memory and CPU for large recipes rather than container-side compute in the standard static deployment and retain the result as the expected envelope for this version.

Test a denied or invalid condition as well: submit harmless input near the resource or format limit associated with this boundary: large operations exhaust browser memory even though the server is healthy. CyberChef should fail in a diagnosable way and should not overwrite healthy state. Return the valid condition, rerun the sample and attach the relevant redacted logs. Those artifacts give a future rollback decision concrete evidence.

Move the repeatable infrastructure work to Dockup

For stateless CyberChef, Dockup's job is narrow and useful: start the pinned image, keep port 80 private, attach the HTTPS route and replace the container without inventing storage. The deployment can target Dockup infrastructure or a customer-attached server.

Finish the application configuration: publish the static interface on a trusted HTTPS origin. Dockup should preserve the CyberChef runtime settings while the operator confirms this local requirement: no database for the standard client-side build. Run this acceptance action: build a multi-step recipe, export it, process a representative file and confirm the output hash matches a known value. Optional authentication or external services should be represented as separate configuration and dependencies so the deployment remains accurate.

Frequently asked questions

What does CyberChef need for a production deployment?

Route the CyberChef container on port 80 through one HTTPS origin. The standard CyberChef build needs no database or separate persistent runtime service. Do not call CyberChef ready until you can build a multi-step recipe, export it, process a representative file and confirm the output hash matches a known value.

Which CyberChef data belongs in a backup?

The standard CyberChef image has no required application-data mount. Preserve its deployment configuration and back up any connected state separately; recovery passes when the pinned static build can be recreated and an exported recipe produces the same known output.

Does CyberChef require HTTPS behind a reverse proxy?

Use HTTPS for the public CyberChef origin and keep port 80 on the internal route. Apply the CyberChef setting correctly: publish the static interface on a trusted HTTPS origin. For CyberChef, HTTPS protects credentials or user content in transit and keeps origin-sensitive client behavior consistent.

How should a CyberChef upgrade be tested?

Deploy the candidate CyberChef image beside the current one and repeat the acceptance transaction with known input. Pay particular attention because CyberChef recipe operations and bundled libraries can change output or compatibility, so the pinned build needs a regression test. The standard container has no data migration, so retain the previous digest until output and compatibility checks pass.