Projects and environments
The project is the application
In Zero, project and "application" are the same thing. There is no separate "application" object to create inside a project: the project holds the public address, the version history, the variables, and the settings.
That has a practical consequence: when you create the project, you already say where the code comes from. There is no second step of "now create the application".
The repository belongs to the project — one source per project. Every service in the project deploys from the same repository, and each one only chooses the folder and the reference. To deploy from another repository, create another project.
The environment
An environment is the target of a deployment and the scope of a configuration. Every project is born with Production — you do not create an environment before deploying for the first time.
An environment is a real boundary, not a label:
| What the environment separates | Consequence |
|---|---|
| Execution space | What runs in one environment cannot see what runs in another |
| Resource quota | One environment does not consume another's capacity |
| Network | Closed by default; what comes in and goes out is explicit |
| Configuration | Variables and secrets can apply to that environment only |
| Blast radius | A problem stays contained in the environment where it happened |
The environment's internal name never appears in the interface or in the public address. It is implementation, and showing an internal identifier in an address is exactly the kind of detail that ages badly.
One project, several services
Inside an environment, a project can have more than one service — a web service answering people and a background process consuming a queue, for example.
With a single service, that layer does not appear: the console shows the service directly. With more than one, the Services section gets content of its own. See Services.
Address and name
The project's name is part of the public address. That is why it accepts only lowercase letters, numbers, and hyphens — the same rules an internet address allows.
- Production uses the short form:
<project>-<organization>. That is the address you hand out. - Other environments carry the environment in the address:
<project>-<environment>-<organization>. - A project with more than one web service gets
<service>-<project>-<organization>for the others; the project still has one canonical address.
Uniqueness is about the final address, not about the name inside the organization: a name that is free in your organization can still produce an address that is taken, and the address decides. The form checks that as you type.
Each web service has one public address. Changing it, under Domains, does not pile up addresses: the previous one stops answering as soon as the new one is live and stays reserved to your organization. See Project address.
Deleting
Deleting a project shuts down everything that runs in it: environments and services go offline, queued deployments are cancelled, and the source and its credentials are revoked. The project disappears from every read and the project's name becomes free; the public address stays reserved to your organization. The history stays recorded — audit, operations, deployments, and versions. It is a destructive operation: the console asks you to type the project's name. See Deleting the project.
A custom domain zone in use by a project refuses to be deleted while the project exists — the correct order is to delete the project first.
Next steps
Was this page helpful?
Report a problem on this pageDo not send passwords, keys, tokens, or customer data.