1# CLI Options for `wasmtime` 2 3The `wasmtime` CLI is organized into a few subcommands. If no subcommand is 4provided it'll assume `run`, which is to execute a wasm file. The subcommands 5supported by `wasmtime` are: 6 7## `help` 8 9This is a general subcommand used to print help information to the terminal. You 10can execute any number of the following: 11 12```sh 13$ wasmtime help 14$ wasmtime --help 15$ wasmtime -h 16$ wasmtime help run 17$ wasmtime run -h 18``` 19 20When in doubt, try running the `help` command to learn more about functionality! 21 22## `run` 23 24This is the `wasmtime` CLI's main subcommand, and it's also the default if no 25other subcommand is provided. The `run` command will execute a WebAssembly 26module. This means that the module will be compiled to native code, 27instantiated, and then optionally have an export executed. 28 29The `wasmtime` CLI will automatically hook up any WASI-related imported 30functionality, but at this time if your module imports anything else it will 31fail instantiation. 32 33The `run` command takes one positional argument which is the name of the module 34to run: 35 36```sh 37$ wasmtime run foo.wasm 38$ wasmtime foo.wasm 39``` 40 41Note that the `wasmtime` CLI can take both a binary WebAssembly file (`*.wasm`) 42as well as the text format for WebAssembly (`*.wat`): 43 44```sh 45$ wasmtime foo.wat 46``` 47 48The `run` command accepts an optional `invoke` argument which is the name of 49an exported function of the module to run. 50 51```sh 52$ wasmtime run foo.wasm --invoke initialize 53``` 54 55## `serve` 56 57The `serve` subcommand runs a WebAssembly component in the `wasi:http/proxy` 58world via the WASI HTTP API, which is available since Wasmtime 18.0.0. The goal 59of this world is to support sending and receiving HTTP requests. 60 61The `serve` command takes one positional argument which is the name of the 62component to run: 63 64```sh 65$ wasmtime serve foo.wasm 66``` 67 68Furthermore, an address can be specified via: 69 70```sh 71$ wasmtime serve --addr=0.0.0.0:8081 foo.wasm 72``` 73 74At the time of writing, the `wasi:http/proxy` world is still experimental and 75requires setup of some `wit` dependencies. For more information, see 76the [hello-wasi-http](https://github.com/sunfishcode/hello-wasi-http/) example. 77 78## `wast` 79 80The `wast` command executes a `*.wast` file which is the test format for the 81official WebAssembly spec test suite. This subcommand will execute the script 82file which has a number of directives supported to instantiate modules, link 83tests, etc. 84 85Executing this looks like: 86 87```sh 88$ wasmtime wast foo.wast 89``` 90 91## `config` 92 93This subcommand is used to control and edit local Wasmtime configuration 94settings. The primary purpose of this currently is to configure [how Wasmtime's 95code caching works](./cli-cache.md). You can create a new configuration file for 96you to edit with: 97 98```sh 99$ wasmtime config new 100``` 101 102And that'll print out the path to the file you can edit. 103 104## `compile` 105 106This subcommand is used to Ahead-Of-Time (AOT) compile a WebAssembly module to produce 107a "compiled wasm" (.cwasm) file. 108 109The `wasmtime run` subcommand can then be used to run a AOT-compiled WebAssembly module: 110 111```sh 112$ wasmtime compile foo.wasm 113$ wasmtime foo.cwasm 114``` 115 116AOT-compiled modules can be run from hosts that are compatible with the target 117environment of the AOT-completed module. 118 119## `settings` 120 121This subcommand is used to print the available Cranelift settings for a given target. 122 123When run without options, it will print the settings for the host target and also 124display what Cranelift settings are inferred for the host: 125 126```sh 127$ wasmtime settings 128``` 129