Cloudflare Workers still needs more time for some Wasm use cases. The related tooling is already marked as a work in progress. Before looking at the problems, it is worth clarifying where it works well: small projects with controlled dependencies, small bundle sizes, and a need for fast execution. A simple proxy service or a static-file-serving service can be a good fit. With Wasm SIMD, you can build something fast without having to worry much about scaling.

Now let's look at the FAQ in the official documentation. The questions in that section are useful because they clearly show the current limitations.

FAQ

  1. Can I publish a Worker that uses a tokio or async_std runtime?
  • Not at the moment. All crates in your Worker project must compile to the wasm32-unknown-unknown target. This is more limited in some ways than x86 and ARM64 targets.
  1. Why isn't X in the worker crate?
  • It probably should be, we just haven't had the time to fully implement it or add a library to wrap the FFI. Let us know if you need a feature by opening an issue.
  1. My package exceeds Workers size limits, what should I do?
  • We're working on solutions here, but in the meantime you'll need to minimize the number of crates your code depends on or strip as much as possible from your .wasm binary. Here are some additional steps you can try: https://rustwasm.github.io/book/reference/code-size.html#optimizing-builds-for-code-size

Let's start with the first question. If you want to use tokio or async_std, you currently cannot. You can still use async itself; that is not the problem. The issue is that many Rust libraries depend on one of these runtimes, and those dependencies can fail when targeting wasm32-unknown-unknown.

You might find a crate you want to use and then discover that it does not work in this environment. The problem may come from the crate itself or from one of its dependencies not supporting the wasm32-unknown-unknown target. In that case, there may not be much you can do directly, but opening an issue is still useful.

The final limitation is package size. If you exceed the Workers size limits, your main option is to reduce dependencies as much as possible. Even adding one or two crates can be enough to hit the limit. You can also strip as much as possible from the wasm binary and try the optimization steps in this Rust and WebAssembly guide. That still may not be enough; in some of my use cases, it was not. As another option, you can contact the Cloudflare team and ask whether a custom limit increase is possible. Or you can run your own environment with workerd and set the limits you need there.

Conclusion

In my opinion, Cloudflare Workers is a strong service, but some Wasm workflows are not fully mature yet. The biggest friction points are around runtime support, dependency compatibility, and size limits. Once these problems improve, Workers will become a much better option for this kind of workload.

Note: If you think there are any omissions or inaccuracies, please let me know.