> ## Documentation Index
> Fetch the complete documentation index at: https://docs.optimism.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Custom Deployments
> Learn how to manage custom deployments with OP Deployer.
While OP Deployer was designed primarily for use with chains that are governed by Optimism, it also supports managing
custom deployments. This is particularly common for RaaS providers, whose customers often request deployments with
custom L1s (or L2s, in the case of L3s) or governance. This guide will walk you through the process of managing these
chains using OP Deployer.
Chains deployed in this way are not subject to Optimism Governance. They may be running customized or unaudited
code. Use at your own risk.
## Bootstrapping
The first step to deploying a custom OP Stack is to bootstrap it onto an L1. This process will:
* Deploy shared management contracts like `SuperchainConfig` and `SuperchainVersions`.
* Deploy contract implementations that will be shared among all OP Chains in this deployment.
* Set up ownership so that you can control the deployment.
You will use the [`bootstrap`](/chain-operators/tools/op-deployer/usage/bootstrap) family of commands on `op-deployer` to do this.
### Bootstrap Shared Contracts
Every OP Chain belongs to a logical deployment group. This group consists of a set of shared contracts that control the behavior
of a group of OP Chains. This includes:
* Pausing bridges
* Signaling which protocol versions are required and recommended
You can deploy a new set of shared contracts for each OP Chain, or you can deploy them once and share across multiple OP Chains.
The choice is up to the deployer. Note that you **cannot** share a set of shared contracts across multiple L1s.
To begin, bootstrap the shared contracts onto your chosen L1 with the following command:
```shell theme={null}
op-deployer bootstrap superchain \
--l1-rpc-url="" \
--private-key="" \
--artifacts-locator="" \
--outfile="" \
--superchain-proxy-admin-owner="" \
--guardian=""
```
This will output a JSON file containing the addresses of the relevant contracts. Keep track of this file, as you will
need it in subsequent steps.
We recommend the following these best practices when bootstrapping:
1. Use Gnosis SAFEs for ownership roles like `guardian` and `superchain-proxy-admin-owner`. The owner **must** be a
smart contract to support future upgrades, so a SAFE is a sensible default.
2. Use a regular EOA as the deployer. It will not have any control over the deployment once the deployment completes.
3. Use a standard contracts tag (e.g. `tag://op-contracts/v2.0.0`). This will make upgrading easier.
### Bootstrapping Implementations
The smart contracts for an OP Chain are deployed using a factory that points to a set of predeployed implementations.
You must deploy the factory and the implementations every time you deploy to a new L1 and whenever new smart
contract versions are released. Implementations are deployed using `CREATE2`, so addresses may be reused if they
already exist on the L1.
You may need to use different versions of OP Deployer depending on which contracts version you are deploying. See the
[releases guide](/chain-operators/tools/op-deployer/reference/releases) for more information on picking the right release.
To deploy the implementations, use the following command:
```shell theme={null}
op-deployer bootstrap implementations \
--artifacts-locator="" \
--l1-rpc-url="" \
--outfile="" \
--mips-version="2" \
--private-key="" \
--superchain-config-proxy="" \
--upgrade-controller=""
```
Similar to the `bootstrap superchain` command, this will output a JSON file containing the addresses of the relevant
contracts. Again, keep track of this file.
The most important address in the implementations file is the OPCM, or OP Contracts Manager. This contract is the
factory that will deploy all the OP Chains belonging to this deployment group. It is also responsible for upgrading between
different contracts versions. Please keep the following **very important** invariants in mind with the OPCM:
* There is a one-to-one mapping between each OPCM, and contracts version.
* Each OPCM is associated with **exactly one** deployment group. This means that you **must** deploy a new OPCM using the
`bootstrap implementations` command for each new deployment group you manage.
## Deploying
After bootstrapping the contracts and implementations, you can deploy your L2 chains with the `apply` command. You
will need to specify a `configType` of `standard-overrides` and set the `opcmAddress` field in your intent to the
address of the OPCM above. **Make sure you call the right OPCM.** Failing to call the right OPCM might lead to
deploying incorrect contract versions, or associating your chain with the wrong deployment.
Make sure that you use the same `l1ContractsLocator` and `l2ContractsLocator` as the ones used in the bootstrap
commands. Otherwise, you may run into deployment errors.
See the following config for an example:
```toml theme={null}
configType = "standard-overrides"
l1ChainID = 11155420
opcmAddress = "0x..."
l1ContractsLocator = "tag://..." # must match the one used in bootstrap
l2ContractsLocator = "tag://..."
[[chains]]
# Chain configs...
```
Once `apply` completes successfully, you can use the `inspect` family of commands to download your chain's L2
genesis and rollup config files.
## Upgrading
The `op-deployer upgrade` command supports upgrades up to `op-contracts/v5.0.0` only. It does **not** support
upgrading from `op-contracts/v5.0.0` to `op-contracts/v6.0.0`. For upgrades beyond v5.0.0, use
[superchain-ops](/chain-operators/tutorials/l1-contract-upgrades/superchain-ops-guide) or interact with the
OPCM directly. See the [notice](/notices/op-deployer-upgrade-deprecation) for details.