# Environments 

Environments in Gadget are separate instances of your application. You can have an environment for each team member, set up environments for manual QA testing, or use environments to run automated tests as part of a CI/CD pipeline.

Each environment has its own:

1.  App URL
2.  Database
3.  Server configurations (e.g. API keys, environment variables, client credentials, etc.)
4.  Runs its own version of your application's code

## Development vs production environments 

There are two main types of environments in Gadget: development and production.

### Development environments 

Development environments are where you build and make changes to your app. This includes adding data models, writing code, and gives you a sandbox to test your application without impacting production. You can create unlimited development environments.

#### Development environment frontends 

Development environment frontends are served by Vite and include features such as:

*   hot module reloading
*   un-minified code for debugging
*   error overlays

It also utilizes [dependency pre-bundling](https://vitejs.dev/guide/dep-pre-bundling) to reduce the time taken to load ESM modules.

### Production environments 

This is your live app. Each Gadget app gets one production environment. Once you are satisfied with the changes made in a development environment, you can [deploy to production](https://docs.gadget-canary.xyz/guides/environments/deployment).

#### Production environment frontends 

In the production frontend, Gadget builds minified assets optimized for production and serves them via a high-performance CDN for the best user experience.

Production frontends will be more performant than development environment frontends due to the different Vite bundle configuration. This is because developer experience is prioritized for development frontends and performance is prioritized for production frontends.

## Managing environments 

### Adding development environments 

1.  Click on the environment selector in the Gadget editor
2.  Click **\+ Create a new development environment**
3.  Give your environment a name and select an existing environment to clone

Cloning an environment copies over everything that can be managed with source control:

*   data models and schema definitions
*   code
*   plugin and connection settings
*   authorization permissions
*   app configuration, such as framework version

The following things are not copied to the new environment and are not managed with source control:

*   data
*   environment variables
*   API keys and connected applications

### Delete an environment 

1.  Go to **Settings → General**
2.  Locate and select **Delete environment** for development environments, or **Reset environment** for production environments
3.  Confirm by entering the name of the environment you are deleting

Deleting an environment will delete all code, data models and data, and configuration for an environment! Make sure you have exported or migrated any data you want to preserve, and saved any code or configuration using a different environment or source control.

### Managing environments with the CLI 

The `ggt env` command lets you manage environments directly from the terminal without opening the Gadget editor. It resolves the target application from the `--app` flag, `.gadget/sync.json`, or an interactive prompt.

**Create a new environment:**

```sh
# Create an empty environment
ggt env create dev-2 --app my-blog

# Clone from an existing environment
ggt env create dev-2 --from development --app my-blog
```

**Switch the active environment** in your local sync directory (updates `.gadget/sync.json` without triggering a sync):

```sh
ggt env use dev-2
```

**Delete an environment:**

```sh
ggt env delete dev-2 --app my-blog
```

**Unpause a paused environment:**

```sh
ggt env unpause dev-2 --app my-blog
```

For full reference documentation, see the [`ggt env` reference](https://docs.gadget-canary.xyz/reference/ggt#ggt-env).

### Environment domains and APIs 

Your application has separate domains for each environment.

*   Development domain: `https://<your-app>--<your-environment>.gadget.app/`
*   Production domain: `https://<your-app>.gadget.app/`

To access the frontend or make API requests, use the appropriate domain. For example:

*   Development GraphQL API: `https://<your-app>--<your-environment>.gadget.app/api/graphql`
*   Production GraphQL API: `https://<your-app>.gadget.app/api/graphql`

#### Specifying environments using the API client 

A Gadget API client can connect to different environments by setting the environment option:

```typescript
import { YourAppClient } from "@gadget-client/your-app";

export const api = new YourAppClient({
  environment: "development",
});
```

To dynamically switch based on the `NODE_ENV`:

```typescript
import { YourAppClient } from "@gadget-client/your-app";

// Defaults to development if NODE_ENV is not "production"
export const api = new YourAppClient();
```

`NODE_ENV` will be set to "development" for every development environment. When working with multiple development environments, it is best to specify the environment manually.

#### Specifying environments when using a script tag 

A script tag can be used to install your app's API client. You must also specify the environment as part of your app's domain when using this script tag.

For example:

```html
// in use a script tag to install the API client for an environment
<script src="https://your-app--development.gadget.app/api/client/web.min.js"></script>
<script>
  // create a new instance of the Gadget client at the api global
  // connected to the development environment
  window.api = new YourAppClient();
</script>
```

#### Specifying environments using GraphQL 

For raw GraphQL requests, adjust the endpoint based on `NODE_ENV`:

```typescript
let endpoint;
if (process.env["NODE_ENV"] === "production") {
  endpoint = "https://your-app.gadget.app/api/graphql";
} else {
  endpoint = "https://your-app--development.gadget.app/api/graphql";
}

const result = await fetch(endpoint, {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    query: "query { gadgetMeta { applicationName } }",
  }),
});
```

## Working in teams 

Each developer working on the same app should have their own development environment to be used as a personal development sandbox. This prevents any conflicts with other developers working on the same app, and functions the same as building on a local machine.

[Gadget's CLI, `ggt`](https://docs.gadget-canary.xyz/guides/development-tools/cli), can be used to pull down a development environment's code and configuration to a local machine. This enables developers to use [source control](https://docs.gadget-canary.xyz/guides/source-control) and branching to manage their applications.

Source control, CI/CD, and suggested deployment workflows can be found in the [deployment docs](https://docs.gadget-canary.xyz/guides/environments/deployment).

### Building Shopify or BigCommerce apps as a team 

Shopify and BigCommerce app connections are not copied over when creating new environments.

Each developer should create a new Shopify or BigCommerce app and connect it to their development environment.

This will help to reduce noise from webhooks and gives each developer a clean and unique development sandbox.

### Multiplayer 

Gadget development environments do support multiplayer. This means that two or more developers can build in the same environment at the same time. This is potentially useful for debugging, pair programming, or working on different parts of an application in parallel.

You can see the team members currently working on a single environment in the Gadget editor's environment selector.

Be careful when using multiplayer! Developers have the ability to overwrite each other's code, change branches suddenly, or update configuration, which may result in lost work if work is not committed to source control regularly.