Projects provide you with a way to organize the services that belong to a particular application. For example, your app might have a static frontend dashboard site, a GraphQL backend service, a few cron jobs, and a SQL database. Putting those services into a project makes finding and managing related services easier.

Each project starts with one environment. Environments help you organize the deployments of your application, and you can add as many environments as you need in a project. Typically, people set up Production and Staging environments, but you can add others to meet your team’s unique needs.

Creating a project

Create a new project from the Render Dashboard by clicking New > Project:

Navigating to project creation

You’ll be prompted to name your project. We recommend using the name of the application you’re building. Next, you’ll be asked to name your first environment. Each project must have at least one environment in it. If you don’t already have a plan for how you’ll organize, then using the default of “Production” is a reasonable choice. You can always change it later.

Create a project dialog

Once you click the “Create a project” button, you’ll land on the project page.

Moving services to environments

If there are no services in your environment, you’ll be prompted to create new services or move services into the environment if you already have services in your account.

Move services into a new environment

When you create a new service from an environment context, the service will be automatically added to the environment. If you already have services in your Render account or team, you can move those services into the environment.

There are other ways to move services; one way is to select a handful of services to bulk move them.

Move services in bulk

Additionally, if you’d like to move a service from one environment to another environment, or remove it from the project entirely, you can find the option “Move” in the ”···” menu on the service row. This action is available in the services list on the project page and the list of ungrouped services on the overview page.

Service dropdown menu

The Dashboard homepage lists your Projects at the top:

Dashboard homepage with projects

Selecting a project navigates you to its overview page.

Updating and deleting projects and environments

You can access settings at the top right of the project page by clicking on the gear icon. In settings, you can rename your projects and environments or delete them.

Project settings page

Environment variables and secrets

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

You can optionally restrict 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


Can I use just environments? Or just projects?

Projects and environments work best when used together. You can’t create an environment wholly detached from a project, nor can there be a project with no environments in it. That said, you can undoubtedly have a single project with many environments. Or you can have many projects, each with a single environment.

You’ll be able to get very far with just one project or just one environment. But let’s say your operational needs change, and you want an environment for staging your app. We designed Projects and Environments to adapt to changing levels of complexity without you having to refactor your organization “from 1 to n“.

Does the environment named “Production” have any special behavior?

Nope, “Production” is our default suggestion based on how teams typically structure their services. You can name your environments anything you’d like. We don’t have any distinct behavior for specific environment names.

What impact do projects and environments have on how my services behave?

None! Projects and environments are purely organizational. Moving a service between projects won’t cause a redeploy or interruption in traffic. Environments do not currently have network isolation, so services can hypothetically still connect across environments. Renaming projects or environments incurs no downtime for the services within them.

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

Yes! Blueprints are great for creating and updating your services. Projects and environments are the best way to organize your services, databases, and other resources. Today, you can move your Blueprint-managed resources into projects and environments. Syncing updates to your render.yaml will keep those resources right where you put them, so your Render Dashboard is always tidy.

In the future, we’ll expand our Blueprint support to cover creating and managing projects and environments.

How can I put preview environments into a project?

Preview environments are a Blueprint-specific feature rather than a project feature. To access your Preview environments, go to the Blueprints tab as before.

How do teams interact with projects and environments?

Each team has its own set of projects and environments. In the past, many users have used teams to organize their services. From now on, we recommend using projects instead for organizational purposes.

Why can’t I use the same service name in different environments?

Currently, we prevent a single account from having duplicate service names. It’d be challenging to know what each service is in the flat overview list. But having the same service name in different projects or environments is a reasonable organizational strategy. Since there’s no ambiguity, we’ll relax this limitation soon.

Are there limits to the number of projects and environments?

Projects are limited to users on a Team, Organization, or Enterprise plan. Each project can contain as many environments as you need.