Render **projects** enable you to organize your services by application and environment:

For example, one of your applications might include a static site, a GraphQL backend, and a database. By adding all of these services to the same project, you can find and manage them more quickly.

Each project has one or more **environments** (such as **Production** in the screenshot above). If you run staging and production versions of your app, you can add each version's services to a different environment.

You can also set **[environment-specific controls](/content/docs/projects#environment-specific-controls/index.html):**

- [Define environment variables and secret files](/content/docs/projects#scoped-configuration/index.html) that only services in a single environment can access.
  - Prevent your staging services from inadvertently using a production-specific credential (or vice versa).
- Designate an environment as [protected](/content/docs/projects#protected-environments/index.html) so that only your workspace's admins can make potentially destructive changes to its resources.
- [Block private network traffic](/content/docs/projects#blocking-cross-environment-traffic/index.html) from entering or exiting a specific environment.
  - Prevent your staging services from inadvertently accessing a production database (or vice versa).

## Setup

**Hobby workspaces can have up to two environments per project.**

To create additional environments, [upgrade your workspace](/content/docs/team-members#change-a-workspaces-plan/index.html).

### Create a project

1. In the [Render Dashboard](https://dashboard.render.com/), click **New > Project**:

The following form appears:

2. Provide a name for your new project, along with a name for its first environment.
   - Both of these names are for your own informational purposes. You can change them later.
3. Click **Create a project**.

That's it! You're redirected to the page for your new project.

### Add services to an environment

If an environment in your project is empty, it displays buttons for creating a new service or moving some of your workspace's existing services into the project:

You can specify a new service's associated project and environment during the creation flow.

You can bulk-move services to an environment by selecting them in your workspace's service list and then clicking **Move**:

You can also move an individual service by opening its **•••** menu and clicking **Move**.

### Open a project

Your workspace's homepage in the [Render Dashboard](https://dashboard.render.com/) lists all projects at the top:

Click a project to open it. Services belonging to a project appear on that project's page, _not_ on your workspace's homepage.

### Modify a project

- To add an environment to a project, click **\+ Add environment** at the top right of the project's page.
- To configure an existing environment, click the **•••** menu at the top right of that environment's section on the project's page.
- To rename or delete an entire project, click **Settings** in the left pane of the project's page.

**Important:**

- Deleting a project deletes _all_ of its associated environments and services.
- Deleting an environment deletes all of its associated services.

## Blueprint support

[Blueprints](/content/docs/infrastructure-as-code/index.html) (Render's infrastructure-as-code model) support creating projects and environments, along with assigning your resources to them:

yamlCopy to clipboard

```yaml
projects:
  - name: my-project
    environments:
      - name: production
        # These resources will belong to the my-project/production environment.
        # Do not duplicate these definitions at the root level.
        services:
          - name: my-web-service
            type: web
            envVars:
              - key: MY_ENV_VAR
                value: my-value
        databases:
          - name: my-database
            type: postgres
            envVars:
              - key: DATABASE_URL
                fromDatabase:
                  name: my-database
                  property: connectionString
        envVarGroups:
          - name: my-env-group
            envVars:
              - key: MY_ENV_VAR
                value: my-value
        # Environment-specific settings
        networking:
          isolation: enabled
        permissions:
          protection: enabled
```

For details, see the [YAML reference](/content/docs/blueprint-spec#projects-and-environments/index.html).

## Environment-specific controls

### Scoped configuration

[Environment groups](/content/docs/configure-environment-variables#environment-groups/index.html) are a helpful way to share environment variables and/or secret files across multiple services in your workspace.

You can optionally scope an environment group to a single project environment. This helps you share configuration across multiple services in that environment, while also ensuring that services in _other_ environments _can't_ use that environment group.

Move an environment group into a project environment from the group's info page by clicking **Manage > Move group**:

After you move your environment group, it appears on the corresponding project's overview page:

### Protected environments

Workspace members with the [**Admin** role](/content/docs/team-members#member-roles/index.html) can designate any project environment as **protected**. This restricts other members from performing potentially destructive actions ( [listed below](/content/docs/projects#restricted-actions/index.html)).

#### Steps to configure

1. Go to your project's page in the [Render Dashboard](https://dashboard.render.com/) and scroll to the environment you want to configure.
2. Click the **•••** menu at the top right of the environment, then click **All settings**.
3. Scroll down to the **Permissions** section and click **Edit**:

4. Select **Protected** and click **Save**.

Protected environments display a label and a lock icon on your project's page in the Render Dashboard:

#### Restricted actions

**Important:** If your protected environment includes resources that are managed via [Blueprints](/content/docs/infrastructure-as-code/index.html), non- **Admin** workspace members _can_ still modify those resources by publishing an update to the corresponding `render.yaml` file.

Only **Admin** workspace members can perform the following actions in a protected environment:

**Resource management**

- Deleting any of the environment's resources (services, [environment groups](/content/docs/projects#scoped-configuration/index.html), etc.), or deleting the environment itself
- Creating new resources in the environment
- Moving resources into or out of the environment

**Operational controls**

- Modifying access control IPs for any Render Postgres or Key Value instance in the environment
- Suspending or resuming any service in the environment
- Toggling [maintenance mode](/content/docs/maintenance-mode/index.html) for any service in the environment
- Accessing the shell for any service in the environment

**Secret values**

- Viewing or modifying environment variables or secret files for any service or environment group in the environment
- Viewing passwords or connection URLs for any Render Postgres or Key Value instance in the environment

### Blocking cross-environment traffic

By default, all of your Render services in the same region can communicate over their shared private network.

You can configure an environment to _block_ private network traffic from crossing its boundary. If you do, services _within_ the environment can still communicate:

Production

Staging

✅

✅

❌

Web service

DB

Web service

DB

This helps you prevent your staging services from inadvertently accessing a production resource (or vice versa).

**This setting only affects _private network_ traffic.**

- Web services and static sites in the environment can still receive public internet traffic at their `onrender.com` subdomain, _including_ traffic originating from your services outside the environment.
- Render Postgres and Key Value instances in the environment can still receive traffic at their external URL from [allowed IPs](/content/docs/postgresql-creating-connecting#restricting-external-access/index.html).
- Workspace members can still access services in the environment over [SSH](/content/docs/ssh/index.html).

- In a [protected environment](/content/docs/projects#protected-environments/index.html), only **Admin** workspace members can access the shell for services in the environment.

#### Steps to configure

Toggling this feature does not trigger any deploys or cause any interruptions for your running services.

1. Go to your project's page in the [Render Dashboard](https://dashboard.render.com/) and scroll to the environment you want to configure.
2. Click the **•••** menu at the top right of the environment, then toggle **Block cross-environment connections**:

**Enabling this feature does not terminate any active network connections.**

To ensure that all existing connections are terminated, you can restart your services in the environment.

You're all set! Your environment now blocks private network traffic from crossing its boundary.

### Environment-level IP rules

With a **Scale** or **Enterprise** [plan](/content/pricing/index.html), you can set inbound IP rules for all services in a particular environment. These rules apply to inbound connections from the public internet.

For details, see [Inbound IP rules](/content/docs/inbound-ip-rules/index.html).

## FAQ

###### Does an environment named 'Production' or 'Staging' have special restrictions or capabilities?

**No.** Render does not apply special logic to any environment based on its name. The examples above use "Production" and "Staging" because they're common.

###### Will my service behave differently after I add it to a project?

**Possibly.** If you've configured any [environment-specific controls](/content/docs/projects#environment-specific-controls/index.html) for the service's corresponding environment, those controls apply to the service.

For example, if the service's environment [blocks cross-environment network traffic](/content/docs/projects#blocking-cross-environment-traffic/index.html), the service can no longer communicate over your private network with services outside the environment.

###### Can I use projects and environments with Blueprints (Render's infrastructure-as-code model)?

**Yes.** You can define projects and environments in your `render.yaml` file, then assign new and existing resources to them.

For details, see the [YAML reference](/content/docs/blueprint-spec#projects-and-environments/index.html).

###### Are preview environments tied to projects?

**No.** You manage your workspace's [preview environments](/content/docs/preview-environments/index.html) with [Blueprints](/content/docs/infrastructure-as-code/index.html), not projects. A preview environment can include services that belong to any number of different projects.

###### Can I use the same service name in multiple project environments?

**No.** All of a workspace's services must have unique names—even services that belong to different project environments.