Project

What is a Project in cloud hosting?

A project is an isolated resource container in OpenStack that groups users, compute instances, networks, storage volumes, and other cloud resources under a single administrative boundary. In older OpenStack documentation, you may see projects referred to as "tenants," but "project" is the current standard term.

Every resource you create in an OpenStack cloud belongs to exactly one project. When you launch an instance (virtual machine), create a volume, or configure a security group, that resource exists within your current project and is invisible to users in other projects unless explicitly shared.

Related Terms

• Instance: A virtual machine running within a project, such as a web server or database host that consumes the project's compute quota.
• Security Group: A set of firewall rules scoped to a project, such as rules allowing SSH access only from specific IP addresses.
• Private Network: An isolated network segment within a project, such as a backend network connecting application servers to database servers.
• Quota: A limit on how many resources a project can consume, such as a maximum of 20 instances or 500GB of storage.
• Virtual Private Cloud: A concept similar to a project that provides isolated networking and resources, such as AWS VPCs or Google Cloud projects.

Why Projects Exist

Without projects, all users on a shared cloud platform would see and potentially access each other's resources. A developer testing a new application could accidentally delete a production database. A billing system could not track which team or customer used which resources. An administrator could not limit how much of the cloud's capacity any single user could consume.

Projects solve these problems by creating hard boundaries between different groups of resources. Each project has its own set of users with defined roles, its own quotas limiting resource consumption, and its own isolation from other projects. This separation enables multi-tenancy, where many different customers, teams, or environments can share the same physical cloud infrastructure without interfering with each other.

What Do Projects Actually Do?

• Isolate resources: Instances, volumes, networks, and other resources in one project are invisible to users in other projects by default.
• Define ownership: Every resource belongs to exactly one project, establishing clear accountability for what exists and who created it.
• Enforce quotas: Administrators set limits on how many instances, vCPUs, RAM, storage volumes, and floating IPs each project can use.
• Control access: Users are granted roles within specific projects, determining what actions they can perform on that project's resources.
• Enable billing: Cloud providers track resource usage per project to generate accurate invoices for each customer or department.
• Separate environments: Teams can use different projects for development, staging, and production to prevent accidental cross-environment changes.

When Would I Use a Project?

You would use a project whenever you need to group related resources together with defined boundaries. Common scenarios include:

• Customer isolation: A cloud provider creates one project per customer so each customer only sees their own resources and receives their own bill.
• Department separation: A company creates separate projects for engineering, marketing, and finance so each department manages its own cloud resources independently.
• Environment separation: A development team creates separate projects for development, staging, and production environments to prevent accidental changes to production systems.
• Application isolation: A team creates separate projects for different applications so that a misconfiguration in one application cannot affect another.
• Cost tracking: An organization creates projects aligned with cost centers so cloud spending can be tracked and allocated accurately.

When Would I NOT Use a Project?

You would not create a new project when:

• Resources need to communicate frequently: Instances in different projects cannot communicate over private networks by default. If two applications need low-latency private network communication, they should be in the same project.
• Shared resources are required: Some resources like custom images or volumes cannot be easily shared across projects. If multiple teams need access to the same resources, consider keeping them in a shared project with appropriate access controls.
• Management overhead is not justified: Each project requires separate quota management, user assignments, and potentially separate billing. For a small team running a few related applications, a single project is often simpler.
• You need a single view of all resources: Administrators working across many projects must switch between them to see resources. If unified visibility is important, fewer projects may be better.

Real-World Example

Company A runs a SaaS application serving multiple enterprise customers. Each customer's data must be strictly isolated, and each customer is billed separately for their cloud usage.

Company A creates one OpenStack project per customer. Customer 1's project contains their dedicated instances, private network, and storage volumes. Customer 2's project contains a completely separate set of resources. Neither customer can see or access the other's infrastructure.

When Customer 1's usage spikes, their project's quotas limit how many additional instances they can launch, protecting the shared cloud from being overwhelmed. When Company A generates monthly invoices, they query each project's resource usage from CloudKitty to produce accurate, per-customer bills.

If Company A later onboards Customer 3, they simply create a new project, assign the customer's users to it, set appropriate quotas, and the new customer can immediately begin launching resources in their isolated environment.

Frequently Asked Questions

Can a user belong to multiple projects? Yes. A user can be assigned to multiple projects with the same or different roles in each. When logged into the Horizon Dashboard or using the OpenStack CLI, the user selects which project they want to work in. Any resources they create will belong to that currently selected project.

What happens to resources when I delete a project? Deleting a project removes all resources contained within it, including instances, volumes, networks, security groups, and floating IPs. This action is irreversible, so you should ensure all important data is backed up before deleting a project.

Can resources be moved between projects? Most resources cannot be moved directly between projects. To migrate a workload to a different project, you typically need to create a snapshot or backup of the resource, then recreate it in the target project. Some resources like images can be shared between projects without moving them.

How do project quotas work? Administrators set quotas on each project defining maximum resource limits, such as 50 instances, 100 vCPUs, 200GB RAM, and 1TB storage. When a user tries to create a resource that would exceed a quota, the request fails with an error message indicating which quota was exceeded. Users can request quota increases from administrators.

What is the difference between a project and a domain in OpenStack? A domain is a higher-level container that groups multiple projects and users together. Large organizations use domains to separate different business units, each with their own set of projects. A project always belongs to exactly one domain. Most users interact primarily with projects rather than domains unless they are cloud administrators.

Summary

• A project is an isolated resource container that groups users, instances, networks, and storage under a single administrative boundary.
• Projects enable multi-tenancy by keeping different customers, teams, or environments completely separated on shared cloud infrastructure.
• Each project has its own quotas, user access controls, and resource tracking for billing purposes.
• The term "tenant" in older OpenStack documentation refers to the same concept as "project."
• Use separate projects when you need resource isolation, independent billing, or environment separation; use a single project when resources need to communicate easily or when management simplicity is more important.