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 130# Additional options 131Many of the above subcommands also take additional options. For example, 132- run 133- serve 134- compile 135- explore 136- wast 137 138are all subcommands which can take additional CLI options of the format 139 140```sh 141Options: 142 -O, --optimize <KEY[=VAL[,..]]> 143 Optimization and tuning related options for wasm performance, `-O help` to see all 144 145 -C, --codegen <KEY[=VAL[,..]]> 146 Codegen-related configuration options, `-C help` to see all 147 148 -D, --debug <KEY[=VAL[,..]]> 149 Debug-related configuration options, `-D help` to see all 150 151 -W, --wasm <KEY[=VAL[,..]]> 152 Options for configuring semantic execution of WebAssembly, `-W help` to see all 153 154 -S, --wasi <KEY[=VAL[,..]]> 155 Options for configuring WASI and its proposals, `-S help` to see all 156``` 157 158For example, adding `--optimize opt-level=0` to a `wasmtime compile` subcommand 159will turn off most optimizations for the generated code. 160 161## CLI options using TOML file 162Most key-value options that can be provided using the `--optimize`, `--codegen`, 163`--debug`, `--wasm`, and `--wasi` flags can also be provided using a TOML 164file using the `--config <FILE>` cli flag, by putting the key-value inside a TOML 165table with the same name. 166 167For example, with a TOML file like this 168```toml 169[optimize] 170opt-level = 0 171``` 172the command 173```sh 174$ wasmtime compile --config config.toml 175``` 176would be the same as 177```sh 178$ wasmtime compile --optimize opt-level=0 179``` 180assuming the TOML file is called `config.toml`. Of course you can put as many 181key-value pairs as you want in the TOML file. 182 183Options on the CLI take precedent over options specified in a configuration 184file, meaning they're allowed to shadow configuration values in a TOML 185configuration file. 186