Repository navigation
stellar contract install|deploy build the current project and install/deploy all built #2047
Description
What problem does your feature solve?
Currently, deploying a Soroban contract requires two separate commands:
stellar contract build && stellar contract deploy --wasm target/wasm32v1-none/release/contract.wasmThis is repetitive and error-prone. Users must remember the full path to the built wasm file, and if they forget to build before deploying, they may deploy stale code. This adds friction to the development workflow.
What would you like to see?
When stellar contract deploy is run inside a directory containing a Cargo.toml (i.e., a Soroban contract project), the CLI should:
- Automatically detect that it's in a contract project directory
- Run the build step (
stellar contract build) if no--wasmargument is provided - Locate the resulting wasm file and deploy it
This would simplify the workflow to just:
stellar contract deployThe CLI already knows how to build contracts via stellar contract build, so this would leverage existing functionality to provide a more streamlined experience.
What alternatives are there?
- Status quo: Continue requiring explicit
stellar contract build && stellar contract deploy --wasm <path> - Shell alias/script: Users can create their own wrapper scripts, but this adds setup overhead and isn't portable
- Makefile/just recipes: Similar to above, requires additional project setup
Activity
leighmcculloch commentedon Jan 29, 2026
👋🏻 This would be pretty convenient I think.
fnando commentedon Jan 29, 2026
Should we ask for confirmation before deploying contracts? Maybe we can ask for confirmation and have an optional
--confirmto bypass it.tupui commentedon Jan 29, 2026
Why? You call deploy to deploy, not build. But adding
--buildand--no-buildcould be good to @leighmcculloch 's point 👍 and default to build maybe.I also have something in my makefile for that. I am going back and forth on the build no build no having a settings vs doing -o or not as I do now would be an improvement.
fnando commentedon Jan 29, 2026
When you're deploying, you're explicit about the intent, by proving the wasm. I guess I'm just trying to keep the same intentionality.
I'm 100% against mixing up build behavior through flags on the deploy command. If we're optimizing flows, it must be as simple as it can be. If they need this level of control, we should instruct users to use
build+deploywith flags instead.tupui commentedon Jan 29, 2026
If we can do
deploywithout wasm and don't build then that's dangerous IMO as you are not necessarily sure about the state of the build.fnando commentedon Jan 29, 2026
right, that's why I'm against having
--build/--no-build, and in favor of always building when no wasm is provided.The remaining question is about deploy, not build: I'm on the fence about uploading multiple contracts without confirming (or using something like a
--confirm).wdyt, @leighmcculloch?
leighmcculloch commentedon Jan 29, 2026
I don't think we need a confirm, build, or no-build option. If you're running deploy it's clear the intent is to deploy.
I think the real question is: when you're interacting with mainnet, should we have some sort of confirmation when any command is going to perform an operation? Maybe. And I think we should discuss that in the context of any command that performs an operation on-chain, rather than this one in isolation.
leighmcculloch commentedon Jan 29, 2026
I've opened a separate issue to consider a confirmation step for all operations when interacting with mainnet:
leighmcculloch commentedon Jan 29, 2026
I think we're also discussing that sometimes the stellar-cli may do something you don't expect and may be surprising. The CLI has the action log as a feature, but it is hard to use. To address this I think we can also make better use of audit logs as a concept. I've opened a separate issue for that:
tupui commentedon Jan 29, 2026
Yes and yes 🙌 very good ideas! And we need to figure out the key handling to me that should have a higher priority.
willemneal commentedon Jan 29, 2026
Perhaps instead of the directory determining the deployed wasm, a
-por--packageargument would signal that that would signal that the contract should be built.The only downside I see to this is the added complexity of the arguments of deploy. If you can build with it then it would follow that you would need to be able to pass the required optional arguments to
contract build. Thus deploy's arguments would become bloated.One idea here is to use a metadata section in the
Cargo.tomlor atoolchain.tomllike file to put those args. Personally I think this is better anyway as it would simplycontract buildtoo and allow you to not need to pass--optimizewhen you likely want that as your default.leighmcculloch commentedon Jan 30, 2026
The
stellar contract buildcommand has very few options. I think all the options could be included, and using clap's grouping feature to group the build options in their own section will make the --help still easy to navigate.fnando commentedon Jan 30, 2026
I don't think it's that simple… there are a lot of things going on, like
--alias,--salt, and contructor args… the more we pull in, the more complex it gets to handle all variations.willemneal commentedon Jan 30, 2026
@fnando @mootz12
I think that you should add aI think that it would be surprising to users and seems at odds with the current version of the--workspaceargument, so that it will only deploy all contracts if that is passed unless there is a single contract.deploycommand to deploy more than one contract at a time. It seems that it reuses the sameslopfor each contract deploy even though they likely would have different constructors.Rereading a
--workspacedoesn't makes sense given the reusedslop. Stellar scaffold lets you define the constructor args in a file, but here we don't have that option.The
slopcould be split, e.g.-- --arg1 foo -- --other-contract-args, since this would be one string passed set to theslopargument. However, it's unclear the order the packages would be in and seems error prone.fnando commentedon Jan 30, 2026
cc @leighmcculloch thoughts on ^?
leighmcculloch commentedon Jan 30, 2026
I think if you need to provide constructor args you probably should run the command multiple times. A multi-slop input looks very complicated and non-obvious, and unlikely to be discovered and used.
I think build-deploy could only support a single contract at once, either the current one if you're in the crates repo, or specified via --package.