Skip to main content
We covered how to set your own Environment Variables in the manifest, but you’ll likely need to work with smart contracts locally and on testnets. Additionally you’ll likely need to interact with APIs, both your own and third party ones, with different credentials and different URLs throughout the development lifecycle. Compose supports two manifest environments: local (used when you run goldsky compose start or goldsky compose dev) and cloud (used when your app runs on Compose’s infrastructure after goldsky compose deploy). The active environment is picked automatically based on whether the runtime is executing locally or in the cloud — there is no --env flag on deploy.

Chains and RPCs

There are four primary chain environments Compose is equipped to support: fully local (Foundry, Truffle, Hardhat, etc), locally forked networks (powered by TEVM), testnets and mainnets.

Local chains (Foundry, Truffle, Hardhat)

If you’re developing your compose app locally alongside a smart contract running on a local chain, you can customize the RPC endpoints that Compose uses to read from and write to your contract. You can use hard coded values right in the code, or env variables configured in your Manifest.

Use a local RPC node in code

If you’re just starting out your contract with local development, and building your Compose app at the same time, you can use a Custom chain object right in code. For full reference in custom chain configuration, go here. For full reference on interacting with contracts, go here.

Use a local RPC only in the dev environment

If you already have your contract and compose app deployed but are iterating on the contract and the Compose App locally, you can use env variables to override the RPC only when running locally.

Manifest

Task code

Forking for local Compose development

If you’re just iterating on your Compose app but your smart contract isn’t changing, then a good option for local development can be to use TEVM for forking. This is done by starting your app with the --fork-chains option like so: goldsky compose start --fork-chains. When you use forking, everything in your code will be exactly the same locally as in cloud, but internally we’ll fork all the chains you interact with and we’ll fund all your wallets on the local fork for gas. This allows you to freely iterate on your compose app while testing against a cloned contract and its state. You can also impersonate specific wallet addresses on the fork to test privileged contract methods without needing the private key — see Impersonated wallets for details.

BYO RPCs for mainnets and testnets

By default, Compose uses our internal edge RPCs and our gas-sponsored smart wallets, so you don’t need to worry about wallets, RPCs or gas funding, while giving your app the most optimal performance and durability. However, there may be times when you want to use your own RPC nodes or wallets, which is also fully supported. Below is an example of using your own RPCs and private keys. See Wallets and Chains for more details.

Manifest

Task code

Other environment use cases

Another common need for different environments is interacting with your own, or third party, APIs. For example, you may need to test your compose app against a locally running version of your API for local development. This is pretty straight forward when configuring env vars in your Manifest.

Manifest

Task code