Create a project
A project groups everything for one application: its builds, its environments, and the deploys that run in them.
What a project holds#
Projects sit directly under your organisation. Everything you deploy belongs to exactly one project:
- Builds: container images with their CPU and memory request. A build belongs to a project, not to an environment, so every environment in the project can deploy it.
- Environments, such as
stagingandproduction. Each one holds its own secrets and deploys, and sets shared or dedicated tenancy. - Deploys: a build running in one of the project's environments.
Custom domains are not part of a project. They belong to the organisation, so any project can route a verified domain to its deploys.
Before you start#
You need the Admin or Manager role in the organisation to create, rename or delete projects. Members with the User role see the Projects page as view-only. The dashboard shows view-only (managers and admins can make changes) next to the project count.
When you first sign up, onboarding walks you through creating an organisation, a first project and a first environment. If you did that, you already have a project.
Create a project#
Open Projects
In the dashboard sidebar, under Applications, choose Projects.
Choose New project
Select Projects→New project. The New project dialog opens.
Name it and create it
Enter a Name, such as
web-platformorbilling-api, then choose Create project.
The new project appears as a card on the Projects page with No environments yet. Add one next: builds can be created straight away, but a build can't be deployed until the project has an environment.
Rename a project#
On the project's card, choose Rename, change the name and choose Save. Renaming changes only the display name. Builds, environments, deploys and routes keep working.
Delete a project#
On the project's card, choose Delete and confirm. The dashboard asks: Delete project "name" and everything under it?
How many projects to create#
Use one project per application or service you deploy and version independently. Environments of the same application (staging, production) belong in one project, not in separate projects, because that's how they share builds. You then promote the same build from staging to production.