Projects and Environments

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

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

Each service in a project belongs to exactly one environment in that project (such as Production in the screenshot above). If you run staging and production versions of your app, you can add each version’s associated services to a different environment.

You can also set environment-specific controls:

• Define environment variables and secret files 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 so that only your team’s admins can make potentially destructive changes to its resources.
• Block private network traffic from entering or exiting a specific environment.
  • Prevent your staging services from inadvertently accessing a production database (or vice versa).

Setup

Hobby workspaces support a single project with up to two environments.

To create additional projects or environments, upgrade your workspace.

Create a project

1. In the Render Dashboard, 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 team’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 team’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 team’s homepage in the Render Dashboard 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 team’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 gear icon at the top right of that environment’s section on the project’s page.
• To rename or delete an entire project, click the gear icon at the top right 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.

Environment-specific controls

Scoped configuration

Environment groups are a helpful way to share environment variables and/or secret files across multiple Render services in your team.

You can optionally scope an environment group to a single environment in your project. This helps you share common 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 an project environment from the group’s info page by clicking Manage > Move group:

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

Protected environments

Team members with the Admin role can designate any project environment as protected. This prevents non-Admin members from performing the following potentially destructive actions:

• Deleting any of the environment’s resources (services, environment groups, etc.), or deleting the environment itself
• Viewing or modifying environment variables or secret files for any service or environment group in the environment
• Modifying access control IPs for any PostgreSQL database or Redis instance in the environment
• Suspending or resuming any service in the environment
• Toggling maintenance mode for any service in the environment
• Viewing passwords or connection URLs for any PostgreSQL database or Redis instance in the environment
• Accessing the shell for any service in the environment
• Moving resources into or out of the environment

Important: If your protected environment includes resources that are managed via Blueprints, non-Admin team members can still modify those resources by publishing an update to the corresponding render.yaml file.

Steps to configure

1. Go to your project’s page in the Render Dashboard and scroll to the environment you want to configure.

2. Click the gear icon at the top right of the environment to open its settings page.

3. Scroll down to the Permissions section and click Edit:

   

4. Select Protected and click Save.

Protected environments are indicated by a label and a lock icon on your project’s page in the Render Dashboard:

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:

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.
• PostgreSQL databases and Redis instances in the environment can still receive traffic at their external URL from allowed IPs.
• Team members can still access services in the environment over SSH.
  • In a protected environment, only Admin team 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 and scroll to the environment you want to configure.

2. Click the gear icon at the top right of the environment to open its settings page.

3. Scroll down to the Cross-environment connections section and click Edit:

   

4. Select Blocked and click Save.

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.

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. “Production” and “Staging” are provided as name suggestions because they’re commonly used.

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

Possibly. If you’ve configured any environment-specific controls for the service’s corresponding environment, those controls apply to the service.

For example, if the service’s environment blocks cross-environment network traffic, 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 move any of your Blueprint-managed resources into a project environment. Whenever you sync updates to your render.yaml file, Render keeps those resources in their assigned environment.

Are preview environments tied to projects?

No. You manage your team’s preview environments with Blueprints, 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 team’s services must have unique names—even services that belong to different project environments.