Render projects enable teams to organize their services by application and environment:

Viewing a project environment in the Render Dashboard

For example, your application might consist of a static frontend dashboard, a GraphQL backend service, a few cron jobs, and a PostgreSQL database. By organizing all of these services into a project, you can find and manage them more quickly.

Every project includes one or more environments (such as Production in the screenshot above). If you run production, staging, and test versions of your application, you can add each version’s associated services to a different project environment.

You can also set controls for individual project environments:

  • Each environment can define scoped configuration for values like database URLs and API keys.
  • You can designate an environment as protected so that only your team’s admins can make potentially destructive changes to its resources.

Projects require a team account.


  1. In the Render Dashboard, click New > Project:

    Navigating to project creation

    The following form appears:

    Create a project dialog

  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.

Adding services to a project

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:

An empty project page in the Render Dashboard

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:

Move services in bulk

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

Service dropdown menu

Opening a project

Your team’s homepage in the Render Dashboard lists all projects at the top:

Dashboard homepage with projects

Click a project to open it. Services belonging to a project appear on that project’s page, not on your team’s homepage.

Modifying 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.


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

Environment-level 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:

Moving environment group into an environment

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

Environment groups on project overview page

Protected access

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
  • Modifying environment variables or secret files for any service or environment group that belongs to the environment
  • Moving resources into or out of the environment
  • Modifying access control IPs for any PostgreSQL database or Redis instance that belongs to the environment
  • Accessing the shell for a service that belongs to 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 enable

  1. From your project’s page in the Render Dashboard, click the gear icon at the top right of the environment you want to protect.

    • This opens the settings page for the environment.
  2. Scroll down to the Permissions section and click Edit:

    Editing an environment's permissions in the Render Dashboard

  3. 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:

Indicators of a protected environment in the Render Dashboard


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.

Does my service behave differently if it belongs to a project?

Belonging to a project has no direct effect on a service’s behavior. Project environments are not network-isolated from each other, so services in different environments can intercommunicate as usual.

Note that you can apply environment-scoped configuration to a service only if that service belongs to the corresponding project environment.

Can I use projects and environments with Blueprints (Render’s infrastructure-as-code feature)?

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 project environment, so your dashboard stays tidy.

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.