> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tenderly.co/llms.txt
> Use this file to discover all available pages before exploring further.

# Virtual Environments

> Fork a live network into a private, production-like testnet alternative for dapp development, CI/CD, and staging, over JSON-RPC and a visual dashboard.

Virtual Environments are private blockchain environments that fork a live network and behave like a mainnet you control. They give you the realism of a production chain (oracle prices, live pools, governance state) with none of the cost or risk. You interact with them through the same JSON-RPC your tools already speak, plus an enriched Admin RPC for cheatcodes, and a visual dashboard with a block explorer.

<Frame>
  <img src="https://mintcdn.com/tenderly/bHnTa-WH-G_A7Wtg/images/testnets/27-vnet-home.webp?fit=max&auto=format&n=bHnTa-WH-G_A7Wtg&q=85&s=42e6f39d617130411f3c4005bd0d766d" alt="Virtual Environment Home view showing the Integrate Virtual RPC section with Admin RPC and Public RPC endpoints, setup steps, Network Mirror, Bridge, and Contracts cards, and the attached network with chain IDs and block numbers" width="1600" height="1000" data-path="images/testnets/27-vnet-home.webp" />
</Frame>

## What you can build with them

* **A local node replacement.** Code, test, and debug every part of your dapp (smart contracts, dapp UI, backend, indexing layer) against a network that mirrors mainnet state.
* **CI/CD infrastructure.** Provision a fresh Virtual Environment per pull request, deploy your contracts, run your tests, and tear it down. The [GitHub Actions guides](/virtual-environments/ci-cd/github-actions-foundry) cover the pattern.
* **Staging and demo environments.** Run the full dapp against a forked mainnet for manual QA, community testing, contract audits, or sales demos. Reviewers see a real block explorer; you don't move real funds.
* **Cross-chain testing.** Attach multiple networks to one Virtual Environment and exercise bridge flows end-to-end. The [Multichain Quickstart](/virtual-environments/multichain/quickstart) walks through the setup.

## How do Virtual Environments compare to public testnets?

Public testnets like Sepolia and Holesky run their own isolated chain state, so they lack mainnet liquidity, live oracle prices, and the deployed protocols your dapp depends on. A Virtual Environment forks mainnet (or any of 100+ networks) instead, so you test against real production state, with faucet funds that never run out and full control over account balances, block number, and time. Unlike a public testnet, it stays private to your team and can be created and torn down per pull request.

## Start here

<CardGroup cols={2}>
  <Card title="Quickstart" href="/virtual-environments/quickstart">
    Launch your first Virtual Environment, fund an account, and send a transaction.
  </Card>

  <Card title="Multichain Quickstart" href="/virtual-environments/multichain/quickstart">
    Set up a Virtual Environment that spans multiple networks and run a cross-chain transaction with automatic bridge relay.
  </Card>
</CardGroup>

## Network sync modes

Every Virtual Environment has a network sync mode that controls how it relates to its parent network after creation:

* **Static** (default): The Virtual Environment stays at the forked block head with no live updates from the parent network. State changes only through your own transactions and cheatcodes.
* **State Only Sync**: Storage slots keep tracking live parent-network values until your Virtual Environment writes to them. See [State Sync](/virtual-environments/state-sync).
* **Network Mirror**: A full block-by-block replay of the parent network onto your Virtual Environment, with a visible mempool and time controls. See [Network Mirror Mode](/virtual-environments/network-mirror-mode).

The sync mode is set when you create a Virtual Environment and cannot be changed afterwards. To use a different mode, create a new Virtual Environment.

## The building blocks

These pages explain what each piece of a Virtual Environment does and how it relates to the others. Read them before you need to debug something.

<CardGroup cols={3}>
  <Card title="Explorer" href="/virtual-environments/explorer">
    Inspect transactions, contracts, wallets, and RPC calls on your Virtual Environment through a familiar block-explorer UI.
  </Card>

  <Card title="Unlimited Faucet" href="/virtual-environments/unlimited-faucet">
    Top up native currency or ERC-20 balances on any account, with no real funds required.
  </Card>

  <Card title="State Sync" href="/virtual-environments/state-sync">
    Keep storage slots tracking live mainnet values until your Virtual Environment writes to them.
  </Card>

  <Card title="Network Mirror Mode" href="/virtual-environments/network-mirror-mode">
    Stay block-for-block aligned with the parent network, with a visible mempool and time controls.
  </Card>

  <Card title="Multichain Virtual Environments" href="/virtual-environments/multichain/overview">
    One Virtual Environment, multiple networks, shared identity, unified timeline.
  </Card>

  <Card title="Bridges" href="/virtual-environments/multichain/bridges">
    Automatic relay for LayerZero, Chainlink CCIP, and Across between networks in a Multichain Virtual Environment.
  </Card>
</CardGroup>

## How you interact with a Virtual Environment

You drive a Virtual Environment through four surfaces:

* The **Tenderly Dashboard**, where you create the Virtual Environment, browse transactions, fund accounts, simulate transactions against the environment's current state, and configure settings.
* The **Public RPC**, a standard JSON-RPC endpoint that supports the methods any dapp or library already calls. Use this for your dapp UI, backend, and anything you would expose to external testers.
* The **Admin RPC**, an enriched JSON-RPC endpoint that adds cheatcodes for setting balances, overriding storage, fast-forwarding time, deploying arbitrary bytecode, and synchronising with the live network. Use this from your dev tooling and tests, not from anything externally accessible. The full set of cheatcodes is documented in the [Admin RPC reference](/virtual-environments/admin-rpc).
* The **REST API**, for creating, forking, and deleting Virtual Environments from scripts and CI pipelines. See the [REST API reference](/virtual-environments/rest-api); the [GitHub Actions guides](/virtual-environments/ci-cd/github-actions-foundry) wrap it for pull-request workflows.

<Warning>
  When you share a Virtual Environment with external testers or expose it through a dapp UI, hand out the Public RPC, not the Admin RPC. The Admin RPC lets the caller mutate balances, storage, time, and other network state in ways that can break your tests.
</Warning>

## Common tasks

<CardGroup cols={3}>
  <Card title="Add to a wallet" href="/virtual-environments/interact/add-to-wallet">
    Connect MetaMask or another wallet to your Virtual Environment.
  </Card>

  <Card title="Connect your tooling" href="/virtual-environments/integrations">
    Point Foundry, Hardhat, ethers, viem, or your dapp UI at your Virtual Environment RPC.
  </Card>

  <Card title="Deploy and verify contracts" href="/virtual-environments/develop/deploy-contracts">
    Deploy with Foundry or Hardhat, with automatic contract verification.
  </Card>

  <Card title="Simulate transactions" href="/virtual-environments/interact/simulate-transactions">
    Dry-run transactions against the Virtual Environment's current state before sending them.
  </Card>

  <Card title="Fork a Virtual Environment" href="/virtual-environments/develop/fork-testnet">
    Branch an existing Virtual Environment into a new one at its current state.
  </Card>

  <Card title="Revert state" href="/virtual-environments/develop/revert-state">
    Take snapshots and roll the Virtual Environment back to them.
  </Card>
</CardGroup>

## Supported networks

Virtual Environments work on 100+ EVM networks. See [supported networks](/platform/supported-networks) for the full list.

## See also

* [Quickstart](/virtual-environments/quickstart) for your first Virtual Environment, end-to-end.
* [Stage contracts](/virtual-environments/ci-cd/stage-contracts) to share a Virtual Environment with your team.
* [Admin RPC](/virtual-environments/admin-rpc) and [REST API](/virtual-environments/rest-api) for reference material.
* [Solidity Cheatcodes](/virtual-environments/precompiles) for manipulating state from inside a transaction via the Virtual Environment precompile.
