Projects¶

A project is the unit of resource grouping inside an organization. Every VM, volume, network, cluster, and bucket lives inside exactly one project. Roughly equivalent to an "AWS account" or a "GCP project" — independent quota, IAM, and tagging surface within the organization.

Why projects matter¶

Need	Why projects help
Cost separation	Each project has its own line items on the invoice; chargeback is straightforward
Access boundary	A user assigned only to Project A can't see Project B's resources, even within the same org
Quota isolation	A runaway test in one project can't exhaust the production project's quota
Region pin	A project can be pinned to one region (data-residency / FI-isolation patterns)
Tagging baseline	Org-wide tagging policies can require certain tags on every resource in a project

Most orgs end up with at least: one production project, one non-prod / staging project, and one sandbox for experiments. Larger orgs partition further — per application, per cost-centre, per environment.

The project list¶

On the organization landing page (/), the org card shows one tile per project:

Project tiles on org landing Project tiles. Each shows resource count and last-modified date. Click to enter the project.

Each tile displays:

Project name (centred, bold)
Resource count — total objects in the project across all services
Last-modified date — most recent activity on any resource

Click a tile to enter the project's Console.

Creating a project¶

From the User menu (top-right) → Create → Project, or + Create project on the org landing card.

The Create Project dialog.

The form asks:

Field	Notes
Name	Display name (3–32 chars, alphanumeric + `-`). Used in URLs and as a label everywhere; pick something meaningful
Description	Optional free-text, surfaced in the Cost Explorer and on the tile hover
Default region	`bd-dha-1` / `bd-ctg-1` / `bd-syl-1` — new resources land here unless explicitly placed elsewhere
Tags	Initial tag set; recommended at minimum `cost-center`, `environment`, `app` (see Tagging conventions below)
Quota tier	Defaults inherited from the org; customise to set per-service quotas for this project
Initial members	Optional — add yourself plus other org members with their per-project role

Click Create. The project is available immediately; you land on its Dashboard.

Project Dashboard¶

Already covered in Console layout & navigation → Project Dashboard — the KPI strip, cost breakdown, balance, and top cost generators.

Project settings¶

Open from the sidebar ACCOUNT → Settings while inside the project, or at /project/<id>/account/settings.

Project settings — the per-project version of org settings.

Sections:

General¶

Project name — display name (renaming is safe; IDs don't change)
Project ID — opaque ULID, read-only
Description
Default region
Quota — per-service limits (vCPU, RAM, volume size, public IPs, buckets, ...). Request increases via the support ticket from this page.

Tagging policy¶

Required tags — keys that every newly-created resource must carry
Tag presets — pre-approved value lists per key
Tag inheritance — whether parent-resource tags propagate to children (snapshots, replicas)

Members & roles¶

Detailed on the Roles & permissions page. Project membership is a subset of the org membership — you can only add someone to a project if they're already in the org.

Notifications¶

Spend-alert thresholds (project-specific)
Resource-event notifications (creation / deletion / failure)
Email distribution lists for project events

Danger zone¶

Archive project — disables resource creation; existing resources keep running and continue to be billed. Reversible.
Delete project — terminates all resources and schedules data deletion. Irreversible after a 7-day grace window during which an Owner can restore.

Tagging conventions¶

Tags are key-value pairs you attach to any resource. They flow into:

Invoicing — cost lines are grouped by tag in the Financial portal and exported in Mushak-VAT records
Cost Explorer — drill-down filters
IAM — some roles can be scoped to "resources with tag app=mybank-portal" rather than the whole project
Compliance — data-classification tag carries WORM-retention decisions for Object Lock

Recommended baseline¶

Key	Example values	Why
`cost-center`	`cc-101`, `cc-220`	Chargeback to business units
`environment`	`prod`, `staging`, `dev`, `sandbox`	Don't accidentally delete prod when meaning sandbox
`app`	`mybank-portal`, `payroll-api`	What this resource is for
`data-classification`	`public`, `internal`, `confidential`, `restricted`	Drives Object Lock / encryption / access decisions
`owner`	`team-platform`, `team-data`	Whom to contact
`terraform-managed`	`true`, `false`	Manual cleanup avoidance

Tag at create-time

Back-filling tags is painful and error-prone. Add a tagging policy that requires the baseline at create-time, and use Terraform/IaC to make tags non-optional.

Archiving and deleting¶

stateDiagram-v2
    [*] --> Active
    Active --> Archived: Archive
    Archived --> Active: Unarchive
    Archived --> Deletion_scheduled: Delete (Owner only)
    Deletion_scheduled --> Active: Restore (within 7 days)
    Deletion_scheduled --> Deleted: 7-day grace expires
    Deleted --> [*]

Archive is the soft option: resources keep running, you keep paying, but no new things can be created and existing things can't be modified. Useful when you want to pause work without losing state.

Delete is destructive. After clicking Delete:

The project enters Deletion_scheduled state for 7 days
During that window, an org Owner can Restore
After 7 days, all resources are terminated and data is securely erased
The project ID is permanently retired (cannot be reused)
Billing records for the project are retained 7 years per NBR

Snapshots survive only if you say so

By default, all resources tied to the project are wiped on deletion — including snapshots and backup-as-a-service copies in Object Lock buckets you own within the project. If you need to preserve specific artefacts beyond the project's lifetime, move them to an org-level bucket or a different project before scheduling deletion.

Cross-project patterns¶

Pattern	How
Shared images / templates	Promote a custom image; share across projects in the same org — see Snapshots & Custom Images
Cross-project VPC peering	VPC peer-connect between projects (in the same region) — see VPC
Org-level Object Storage bucket	Create a bucket in a "shared-services" project that other projects' IAM can grant read access to
Centralised SIEM	One project hosts the SIEM cluster; ship logs from all other projects to it