Announcing workers.dev
Workers are pretty neat. I&#x27;ve been using them as a mechanism for serving private Wasabi&#x2F;Backblaze B2 buckets publicly, ideally so I can host project assets with more predictable costs. This is a very practical and useful case for workers, IMO -- it stops unintended outbound egress from origins, and gives better routing -- both B2 and Wasabi peer with CloudFlare to waive any applicable egress fees. So I basically pay a flat $5&#x2F;month + B2&#x2F;Wasabi storage costs (approx $5&#x2F;mo&#x2F;TB) and zero egress, more or less.<p>Overall it&#x27;s worked pretty well; it&#x27;s also useful for doing things like setting up fully &#x27;virtual&#x27; domains when using an object store, e.g. set a CNAME for &#x27;foo.bar.com&#x27; to &#x27;example.com&#x27; and then write a worker that just intercepts every `foo.bar.com` request and routes appropriately. This has worked surprisingly nicely. For example, I host one of my recent projects under <a href="https:&#x2F;&#x2F;riscv.ls0f.pw&#x2F;" rel="nofollow">https:&#x2F;&#x2F;riscv.ls0f.pw&#x2F;</a> but this subdomain doesn&#x27;t really &quot;exist&quot; beyond being a CNAME for example.com; it&#x27;s just routed directly to a B2 bucket subpath, in the background.<p>At the moment I&#x27;m working on a mechanism of automating my worker deployments using GitHub Actions and seeing how writing them in OCaml&#x2F;BuckleScript goes (a much more tedious process), but overall it&#x27;s pretty neat and useful for writing quick routing glue and whatnot.<p>If anyone from the CloudFlare team is reading this, probably the most important feature I&#x27;m looking forward to is resource bindings for cryptographic keys, to be used with the WebCrypto API, so plaintext keys are not visible directly in the worker source code. Is there any ETA on when this might be GA? In my case it&#x27;s the most important feature currently missing, and it&#x27;s really crucial for a lot of practical use cases.<p>EDIT: also, another really useful feature (for me), but admittedly  maybe niche, would be &quot;atomic-compare-and-update worker script&quot;, i.e. I want to submit a JavaScript file to the API and only update the worker iff the new source code is not equal to the existing source code. The reasoning here is that I currently download the worker script and &#x27;diff&#x27; it against the new one as a test, and only upload if they&#x27;re actually different. I could simply re-upload every time but I&#x27;m not sure if this invalidates any &#x27;hot&#x27; worker instances that are already running. Perhaps the upload API can simply be extended with new return codes to indicate this...