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.
Create a new project by clicking on the “New” menu and selecting the Project item.
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.
Once you click the “Create a project” button, you’ll land on the project page.
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.
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.
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.
The Dashboard homepage lists your Projects at the top.
Selecting a project will navigate you to the project overview page.
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.
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“.
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.
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.
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.
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.
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.
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.
Projects are limited to users on a Team, Organization, or Enterprise plan. Each project can contain as many environments as you need.