Skip to main content
A project is an isolated workspace within your organization. Resources, API keys, and collaborator membership are all scoped to projects. Think of a project as the collaboration boundary: when you give someone access to a project, they can use everything inside it. Every organization includes a default project, and you can create additional projects to separate work by team, environment, or workload.

​
How projects work

Each project contains its own set of resources. Collaborators of project A cannot see or access anything in project B, and vice versa. This lets you separate work by team, environment (dev/staging/prod), workload type, or customer.

​
Project visibility

Every project is assigned a level of visibility:
  • Open: Members of the organization can discover and join the project.
  • Closed: Members can discover the project, but can’t join. Access is managed by project and organization admins.
  • Private: Only existing project collaborators and organization admins can see it. Access is managed by project and organization admins.
When you create a project, you explicitly choose its visibility, with Open as the default. A project admin or organization admin can change a project’s visibility between the three states at any time from Project Settings, and switching a project from Open to Closed or Private keeps its existing collaborators. Access to Closed and Private projects is managed by admins. A project admin adds you through the same add-collaborator flow used for any project, and you become a collaborator immediately. When a project is Closed, organization members who aren’t collaborators can see it in their project list but can’t join it. Organization admins are exempt from these limits. They can see every project in the organization, including Closed and Private projects they haven’t joined, and they can join any project without an invitation. To reach a Closed or Private project’s resources or settings, an organization admin has to join it first.

​
Default project

Every organization has a default project. A few things to know about it:
  • All organization members are automatically granted access to the default project.
  • All historical account usage and resources that pre-date projects are attributed to this project.
  • No one can leave the default project.
  • Because all organization members have access, do not use the default project for sensitive resources. Create a separate project for those.

​
Project slugs

A project slug is a short, URL-safe, human-readable identifier for a project. It’s globally unique across Together and distinct from the project’s internal project_id, the permanent identifier behind ownership, permissions, and billing. The slug is the friendly handle. The project_id never changes. You choose a slug when creating a new project, and you can copy any project’s slug from the projects list in Organization Settings. When you create an endpoint with dedicated model inference, the project’s slug becomes part of its endpoint string, <project_slug>/<endpoint_name>. You choose only the endpoint name. The slug prefix is added automatically and makes the endpoint string globally unique.

​
Changing a project slug

Project admins can change an existing project’s slug from Project Settings: find the Project Slug field and select Change. The new slug takes effect immediately.
Changing a slug breaks existing API requests, scripts, and integrations that reference resources by their slug-qualified path (for example, <slug>/<endpoint_name>). There is no redirect from the old slug. Update any references that rely on the old slug.

​
Managing project collaborators

You can manage project collaborators from Settings > Project > Collaborators.

​
Adding collaborators

  1. Go to Settings > Project > Collaborators.
  2. Select Add Collaborator.
  3. Enter the user’s email address.
  4. Select Confirm.
New collaborators are added with the Editor role by default, unless they are an organization admin (who are admins for every project by default). An admin can change their role after they have been added.
The user must already belong to your organization, unless they are being added as an external collaborator.

​
Removing collaborators

  1. Go to Settings > Project > Collaborators.
  2. Find the collaborator you want to remove.
  3. Select the three-dot menu next to their name.
  4. Select Remove User.
  5. Confirm the removal.
Removing a collaborator revokes their access to all resources in the project, including clusters, volumes, SSH access, and management capabilities. This takes effect within minutes.

​
External collaborators

This feature is in beta. Contact support to enable it.
To add users from outside your organization as collaborators, enable Allow external collaborators on the project’s Settings > Project page. Once enabled, you can add external collaborators the same way as any other collaborator. See External collaborators to learn more about their permissions.

​
Project API keys

Each project has its own API keys. These keys authenticate API requests and are scoped to the project’s resources. For details on creating, managing, and rotating API keys, see API Keys & Authentication.

​
Known limitations

Costs in the projects list and in cost analytics may be inaccurate for any project running legacy v1 dedicated endpoints.
If you have external collaborators using unsupported resources, usage may be billed to their organization instead of yours. If your external collaborators are internal company employees, consider migrating them into your organization using SSO or organization invites. Contact support for help with migration.

​
Common project structures

Teams organize projects differently depending on their needs:

​
Next steps

Roles & Permissions

What admins and editors can do within a project

API Keys

Create project-scoped credentials

Cluster Access

Product-specific guide for managing cluster access