Solana Program Deploy Cost Estimator
Rent and account-funding estimator for new upgradeable program deploys. Enter program bytes directly, or use a local .so picker to fill the byte count from file.size. Variable transaction fees and priority fees are excluded from the main estimate.
Use the final binary size in raw bytes. Max accepted program size is 10,485,715 bytes because programdata adds 45 loader bytes. Shared links keep only bytes and cluster.
Mainnet-beta is the default. Switching clusters reruns the same byte estimate.
Reads local file.size only. Nothing is uploaded.
Protocol estimate
Unclaimed SOL recovery angle
Product-specificSuccessful deploys typically drain the temporary buffer. Failed or abandoned uploads can leave that buffer open and its rent reclaimable later.
Main number = protocol rent only. Signature fees, write fees, and priority fees are intentionally excluded because they vary by transaction path and cluster conditions.
How Solana upgradeable deployments use a temporary buffer
Upgradeable program deploys stage the program bytes in a temporary buffer account first. That buffer must be rent exempt, just like the fixed 36-byte program account and the programdata account that holds the deployed bytes on-chain. This estimator focuses on that rent/account funding for a new deploy.
Why buffer and programdata accounts have different overhead
The temporary buffer and the final programdata account both scale with program size, but they are not the same loader account type. The buffer uses 37 + program_bytes, while programdata uses 45 + program_bytes. The program account itself is a fixed 36 bytes and does not grow with the binary.
Why exact-size deployment matters after Solana/Agave 1.18.0
New deploys default to the exact size of the program instead of automatically allocating double-sized headroom. That makes the final .so byte count materially important for both the temporary buffer rent and the programdata rent funded during first deploy.
Worked examples
Program account rent stays fixed at 1,141,440 lamports (0.00114144 SOL) across these examples. The variable cost comes from the buffer and programdata accounts.
| Program size | Temporary buffer rent | Programdata rent | Total rent funded | Reclaimable buffer if left open |
|---|---|---|---|---|
| 100 KB 102,400 bytes | 713,852,400 0.7138524 SOL | 713,908,080 0.71390808 SOL | 1,428,901,920 1.42890192 SOL | 713,852,400 0.7138524 SOL |
| 500 KB 512,000 bytes | 3,564,668,400 3.5646684 SOL | 3,564,724,080 3.56472408 SOL | 7,130,533,920 7.13053392 SOL | 3,564,668,400 3.5646684 SOL |
| 1 MB 1,048,576 bytes | 7,299,237,360 7.29923736 SOL | 7,299,293,040 7.29929304 SOL | 14,599,671,840 14.59967184 SOL | 7,299,237,360 7.29923736 SOL |
Frequently asked questions
Does this include transaction fees or priority fees?
No. The protocol estimate covers only the rent-exempt funding for the temporary buffer, the fixed program account, and the programdata account. Signature fees, write fees, and priority fees depend on the transaction path and are intentionally excluded from the main number.
Does the file picker read or inspect my binary?
No. The page only uses the browser-provided file metadata to read file.size and fill the byte field. The binary stays local to your browser.
Why are the buffer and programdata account sizes different?
Upgradeable loader accounts do not store identical metadata. The temporary buffer uses a 37-byte header plus program bytes, while programdata uses a 45-byte header plus the same program bytes. The program account itself is a separate fixed 36-byte account.
Can a failed deploy leave reclaimable SOL behind?
Yes. A successful deploy normally drains the temporary buffer, but failed or abandoned uploads can leave buffer rent locked until the buffer authority closes that account.