Organizations, Projects & Environments

Everything you run on d2o PaaS lives in a three-level hierarchy:

Organization (acme)
└── Project (shop)
    ├── Environment (production)
    │   ├── Web Application (web)
    │   └── Database (shop-db)
    └── Environment (staging)

• An Organization owns everything: projects, members, secrets, and your plan’s usage limits.
• A Project groups related environments — typically one project per application or service.
• An Environment is a deployment target (for example production or staging) that holds the actual Resources: Web Applications, Background Workers, Databases, and Object Storage.

URLs follow the same shape: the shop project in the acme organization lives at /orgs/acme/projects/shop in the dashboard.

Personal and team organizations

The platform is invitation-only. When you accept an invitation and sign in for the first time, a personal organization is created for you automatically — it is marked Personal in the organization switcher and works like any other organization, except that it cannot be deleted and its ownership cannot be transferred.

For shared work, create a team organization: from the dashboard, choose Create Organization and give it a name and a URL slug (lowercase letters, numbers, and hyphens; the slug appears in URLs like /orgs/acme). Every organization has exactly one owner; the owner and admins can invite members and manage projects. See Access Control for what each role can do.

Only the owner can delete a team organization. Deleting it permanently removes every project, environment, and resource it contains, and asks you to type the organization name to confirm.

Projects

Create a project from the organization page with New Project. A project is mostly a grouping: it holds environments, project-scoped secrets, and the permission grants that control who can work in it. There is nothing to deploy at the project level — that happens in environments.

Deleting a project permanently removes all of its environments and everything in them — apps, databases, buckets and their contents, and secrets — protected environments included. Because of that, a project that contains a protected environment can only be deleted by an Owner or Admin of the organization; anyone else with permission to manage the project can delete projects without protected environments.

Environments

Create an environment from a project’s Environments page with New Environment. Names use lowercase letters, numbers, and hyphens (for example production or staging-eu). The name is fixed at creation, and the type cannot be changed from the dashboard or CLI. Automatic deployment, Protected and Release source can be changed later in the environment’s Settings page (switching to promote-only needs every app to have a built image first); the environment also records a Git branch setting (paas envs update --branch), though apps currently build from the main branch of their platform-hosted repository regardless.

Environment types

Each environment is one of three types: Development, Staging, or Production. The type is how the dashboard groups your environments, and it is how your plan accounts for capacity — limits are tracked per environment type, and some plans may not include every type. See Plans, Limits & Usage.

Git branch and Automatic deployment

Each environment records a Git branch setting (main by default). Builds follow each app’s own source configuration: apps deployed with git push build from the main branch of their platform-hosted repository. Automatic deployment (on by default) releases each new build automatically as soon as it finishes. Changes to an environment’s resources and secrets always roll out, regardless of this setting. With Automatic deployment off, new builds still run but wait as Built in the deployment history instead of going live — useful for production environments where you want to release on your own schedule. See How Builds & Deployments Work. Apps linked to a GitHub or GitLab repository deploy from the branch chosen on the link — see Deploy from GitHub or GitLab.

Release source

Each Environment either builds from source (the default: pushes to its branch are built and deployed) or is promote-only (it never builds; apps run whatever image was last promoted into it from the stage upstream). Together the Environments of a Project form a pipeline, ordered development → staging → production. See Pipelines, Promotion & Rollback.

Protected environments

Mark an environment Protected to guard it against accidental destructive actions. A protected environment cannot be deleted at all — attempting it returns an error until you remove protection in the environment’s settings, which only an organization Owner or Admin can do. Promotions into a protected environment ask for confirmation, and only an organization Owner or Admin can delete a project that contains one. Use it for production.

Deleting an unprotected environment permanently removes the environment and all of its resources, and asks you to type the environment name to confirm. This cannot be undone.

High availability

High availability is set per resource, not per environment: run several instances of an app with its scaling settings — see Scaling & Autoscaling — and give a PostgreSQL database a standby copy with high availability.

Visualizing an environment

An environment’s Resources section opens by default in Topology view: a diagram of every resource in the environment — Web Applications, Background Workers, Databases, and Object Storage — as nodes colored by their current status. When the environment has at least one Web Application, a single public entry point appears with a line to each of them, showing how many are running. A line from an app or worker to a database or bucket appears when it’s attached. A line between two apps appears when one app’s plain environment variable names the other — its name (API_HOST=api) or its public address — labelled with the variable’s name; secrets are never read for this. Resources that share an environment but aren’t wired together have no line between them. It’s a quick way to see everything running in an environment and how it’s actually connected. Switch to Cards or List with the toggle above the diagram for a plainer view of the same resources.

Working from the CLI

The paas CLI mirrors the hierarchy with the -o, -p, and -e context flags:

paas orgs list
paas projects list -o acme
paas envs list -o acme -p shop

paas orgs set-default and paas projects set-default save a default context so you can omit the flags. Each group also has info, create, update, and delete subcommands — run any of them with --help for the exact flags, for example paas envs create --help.

Next steps

• Resources — what you can run inside an environment
• How Builds & Deployments Work — branches, builds, and Automatic deployment in detail
• Inviting People — bring your team into an organization
• Access Control — roles, groups, and project permissions

Favourite organizations

Use the star beside an organization on the dashboard or in the organization switcher to add it to Favourites. Favourites appear above the remaining organizations and are saved to your account across devices. Search includes both sections. Favouriting an organization does not grant access to it.