# Workspaces and projects

Workspaces and projects are the two containers that organise everything on the platform. Understanding the relationship between them makes the rest of the product much easier to navigate.

## The hierarchy

A workspace contains projects. Projects contain deploys, environment variables, and members.

```mermaid
graph TD
  A[Account] --> W1[Workspace: Acme]
  A --> W2[Workspace: Personal]
  W1 --> P1[Project: Marketing site]
  W1 --> P2[Project: Customer portal]
  W1 --> P3[Project: Internal API]
  P1 --> D1[Production deploy]
  P1 --> D2[Preview deploys]
```

## Workspaces

A workspace is the top-level container for a team's work. It owns:

* The list of members and their roles
* The billing relationship and plan
* Workspace-level settings like SSO and audit logs
* All projects created within it

{% tabs %}
{% tab title="Personal" %}
Free, single-member workspaces. Good for evaluating the platform, side projects, or solo work. Limited to 3 active projects.
{% endtab %}

{% tab title="Team" %}
Multi-member workspaces with shared billing and a common plan. Most teams should use this. Includes audit logs and member roles.
{% endtab %}

{% tab title="Enterprise" %}
Team workspaces with extras — SSO, SCIM provisioning, custom data residency, and a dedicated support contact.
{% endtab %}
{% endtabs %}

{% hint style="info" %}
You can belong to multiple workspaces at once. Switch between them using the workspace picker in the top-left of the dashboard.
{% endhint %}

## Projects

A project is a deployable unit. Each project has:

| Component       | What it does                                     |
| --------------- | ------------------------------------------------ |
| **Source**      | The repository or upload that produces the build |
| **Builds**      | The history of build attempts and their outputs  |
| **Deploys**     | Live versions of the project at a URL            |
| **Environment** | Variables and secrets specific to this project   |
| **Domains**     | The custom domains pointing at this project      |

Projects are isolated from each other. Environment variables, secrets, and configurations don't leak across projects in the same workspace.

## When to split into multiple projects

A common question: "should this be one project or two?"

Use **separate projects** when:

* The codebases are different
* They deploy independently
* They have different sets of secrets
* They need different access controls

Use **one project with multiple environments** when:

* It's the same codebase deploying to different URLs
* You want preview deploys per branch
* The differences are configuration, not code

## Related

{% content-ref url="/pages/fb922e107b31a3e9e9fcf81410029e993b0a9afc" %}
[Permissions](/febetlink-docs/documentation/core-concepts/permissions.md)
{% endcontent-ref %}

{% content-ref url="/pages/65332f63d0b6cedd6ac718136ba8d89ec6cc1a4d" %}
[Configuration](/febetlink-docs/documentation/reference/configuration.md)
{% endcontent-ref %}


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://febetlink.gitbook.io/febetlink-docs/documentation/core-concepts/workspaces-and-projects.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.