> For the complete documentation index, see [llms.txt](https://docs.baas.sh/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.baas.sh/baas-cli/deploy.md). # Deploy a contract Deploy a contract with a key from your Vault, and shape how BaaS reads it with mappings and units. `baas deploy` is the everyday way to ship a contract: it compiles your project, deploys the contract with a key from your Vault, waits for the transaction to confirm, and registers the result in your active project. No private key on your machine, and no gas to manage on the BaaS network. Before you start, [sign in](/baas-cli/authentication.md) and [select a project](/baas-cli/projects.md). ## Add your first key `baas deploy` sends the deployment with a key from your project's Vault. You need a key set up on the network you're deploying to. 1. In the **BaaS Dashboard**, open your project's [Vault](/dashboard/vault.md) and click **Add key**. The key is prepared on every network of the project. 2. On a public network, send some native currency to the key's address on that network so it can pay for gas. On the BaaS network, gas is free. The address is on the key's activity page in the Console's [Vault](/baas-console/vault.md). To see your keys and the networks they are set up on at any time: ```bash baas keys:list ``` ## Deploy with the wizard From your Foundry project directory: ```bash baas deploy ``` The wizard walks you through it: 1. **Pick a key**, then **a network** among the ones the key is set up on. 2. **Pick a contract.** The CLI compiles your project and lists the contracts in your source directory (`src/` by default). Interfaces and abstract contracts don't appear, since they can't be deployed. 3. **Fill in constructor arguments**, if the contract has any. 4. **Confirm.** Review the summary, then deploy. The CLI submits the deployment, waits for it to confirm on-chain, and registers the contract. The first deployment can take a few minutes. When it's done, open **Contracts** in the BaaS Console. Your contract is there with its ABI, ready for monitors, automations, and the Executor. ## Deploy with a one-liner Pass the contract, the key and the chain to skip the selection prompts: ```bash baas deploy src/MyToken.sol --key --chain ``` The key is its id, the name you gave it in the Dashboard (`deployer`). The chain is a chain id of the project's network catalog (`11155111`); `--chain-id` works too, as in Forge. `baas keys:list` shows both. Name the contract the way Forge does: a source file (`src/MyToken.sol`), a source and a contract name (`src/Tokens.sol:MyToken`), or just the contract name (`MyToken`). A file with a single contract needs no name. Constructor arguments go last, in order: ```bash baas deploy src/Staking.sol --key --chain \ --constructor-args 0xOwnerAddress 500 ``` Everything after `--constructor-args` is a value, so keep your other options before it. In a terminal, the CLI still shows a summary and asks you to confirm. In CI, it deploys straight away. ## Contracts that use libraries Nothing to do. If your contract calls external libraries, `baas deploy` deploys them first, in the right order, links them into your contract, and registers them too. The summary lists them before you confirm: ``` Contract MyToken (src/MyToken.sol) Libraries Math, Pricing (deployed first) Key deployer Network BaaS ``` Already have a library deployed on that network? Give Forge its address in `foundry.toml`, and the CLI links it instead of deploying a new one: ```toml [profile.default] libraries = ["src/Math.sol:Math:0x1234567890abcdef1234567890abcdef12345678"] ``` Use the library's source path and name, exactly as Forge does. Each `baas deploy` deploys the libraries it still needs; to reuse them across deployments, add their addresses to `foundry.toml` this way. ## Add mappings and units [Mappings](/baas-console/contracts/mappings/custom-mappings.md) and [units](/baas-console/contracts/units/custom-units.md) tell BaaS how to read your contract: which values to track, and in which unit. Both are optional. Without them, BaaS works out what it can from the ABI, and you can always adjust everything later in the Console. ### Name the files after the contract Save each JSON configuration next to your contract's source, with the **contract's name** and a `.mapping` or `.unit` extension instead of `.sol`: ``` src/MyToken.sol src/MyToken.mapping src/MyToken.unit ``` `baas deploy` finds them on its own and sends them with the registration. Provide one, both, or neither. {% hint style="warning" %} The name to use is the **Solidity contract's**, not the file's. A single `.sol` file can declare several contracts, and each one gets its own files. If `src/Tokens.sol` declares `MyToken` and `MyGoodToken`: ``` src/Tokens.sol src/MyToken.mapping src/MyToken.unit src/MyGoodToken.mapping src/MyGoodToken.unit ``` A `Tokens.mapping` or `Tokens.unit` would be ignored. {% endhint %} ### Or point at the files yourself Keeping the files somewhere else, or sharing one between contracts? Pass them with `--mapping` and `--unit`. Each option replaces the automatic lookup for that file only, so you can set one and let the CLI find the other: ```bash baas deploy src/Tokens.sol:MyToken --key --chain \ --mapping ./config/token.mapping --unit ./config/token.unit ``` Paths are relative to where you run the command, and the files are checked before anything is deployed. {% hint style="info" %} Mappings and units apply when BaaS first sees an ABI. Deploying a contract whose ABI is already registered keeps the existing configuration. {% endhint %} ## Next * [Troubleshooting](/baas-cli/troubleshooting.md#deployment) if a deployment doesn't go through. * [Advanced](/baas-cli/advanced.md) when a deployment needs the full power of Forge.