CyberChef Hosting

Encode, decode, encrypt, and convert data with a client-side toolbox that never uploads your input.

Order now No setup fees
  • One click deploy
  • 1 GB RAM Memory needed
  • 15 GB Disk Space Needed
  • From 2 € Price

Tech

Docker image
mpepping/cyberchef:latest
Default port
8000

How CyberChef works

CyberChef presents an input pane, an operation library, a recipe area, and an output pane. Users drag operations into a sequence, tune their parameters, and see the result update as the recipe runs. Recipes can cover encoding, hashing, encryption, compression, parsing, extraction, formatting, and many other technical transformations.

The production application has no server-side processing component: recipes execute in the user’s browser. Recipe definitions can be copied, embedded in a deep link, or saved in that browser profile’s local storage. Input and recipe data stay in the browser for ordinary operations, while Show on map, DNS over HTTPS, and HTTP request deliberately contact external services.

Key CyberChef features

The visual chain makes complex transformations easier to inspect than a long collection of disconnected commands. Analysts can reorder steps, disable an operation, inspect intermediate results, and share a reproducible recipe with another authorised user. The Magic operation can also suggest transformations for data that does not reveal its format immediately.

Because computation happens on the client device, large inputs and expensive recipes are constrained mainly by browser memory and processor capacity. Saved local recipes also belong to the current browser profile and can disappear when its local storage is cleared, so important recipes should be exported or documented outside the interface.

Who uses CyberChef

Security teams use CyberChef to decode indicators, inspect certificates, calculate hashes, parse network-related text, and transform evidence during authorised analysis. Developers use it to test encodings or data formats, while educators build recipes that show each stage of a transformation instead of hiding the process.

CyberChef is a general transformation workbench rather than a malware sandbox, password-cracking service, or substitute for evidence-handling procedures. Users remain responsible for the sensitivity and legality of their input, and operations that contact external systems should be reviewed before confidential data is loaded.

Self-hosting CyberChef: requirements and cost

The hosted server mainly delivers CyberChef’s static application assets, while each visitor’s browser performs the actual recipe work. Concurrent visitors affect asset delivery, but input size, operation count, and recipe complexity consume resources on the user’s device. The catalogue records PostgreSQL and MariaDB as Not required, and saved recipes normally live in browser storage rather than a hosted relational database.

On AvaHost, CyberChef uses Plan 1 at €2. The hosted CyberChef package includes one-click deployment, a custom domain with automated HTTPS, automatic application updates, and scheduled backups. The service supplies the web application only. External map tiles, DNS resolvers, HTTP targets, data sources, and specialised analysis services are not bundled, and users should inspect any recipe that intentionally sends a request outside the browser.

F.A.Q

  • CyberChef begins at €2 on Plan 1. The server primarily distributes the browser application, so most recipe computation happens on each visitor’s device. Concurrent access and static asset delivery affect hosting demand, while very large inputs or complex recipes depend more heavily on the browser’s memory and processor.

  • A custom hostname can serve CyberChef through automated HTTPS after its DNS record points to AvaHost. Share the final address only with authorised users and update saved bookmarks or internal documentation after a domain change. CyberChef itself does not provide a hosted account system, so access policy must follow the deployment’s surrounding controls.

  • Ordinary CyberChef operations run in the browser and do not send the input or recipe to a server. Three documented operations contact external services: Show on map, DNS over HTTPS, and HTTP request. Review recipes before loading sensitive material and use browser developer tools when you need to confirm outbound network activity.

  • Recipes saved through the interface normally use the current browser profile’s local storage rather than a server database. Clearing that browser data or switching profiles can remove them. Export important recipes, store approved copies in a controlled repository, and avoid embedding confidential input in shareable deep links or documentation.