Projects are currently available as an Early Access feature. If you’re on a Team plan or above, you can use Projects today by opting into the Early Access program in your team settings.

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 by clicking on the “New” menu and selecting the Project item.

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 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 your ungrouped services into the environment.

You can create new services or move services into the environment in the future by clicking the plus button in the upper right corner of the environment view.

Move services into an existing environment

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 to…” 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 will navigate you to the project 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


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. Services in different projects or environments can still talk to each other over the network. 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.

Right now, you still link Environment Groups directly with individual services.

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.