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.

​
Common project structures

Teams organize projects differently depending on their needs:

​
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.
  • Organization members cannot leave the default project.
  • It may contain your organization’s legacy API key.
  • 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 a project’s slug. 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>). The old slug doesn’t redirect, so update every reference to it.
  1. Go to Project Settings.
  2. Find the Project slug field and select Change.

​
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. Search for a member of your organization, or enter an email address to invite an external collaborator.
  4. Select Add to project.
New collaborators get the editor role by default, except organization admins, who are admins of every project. An admin can change a collaborator’s role after adding them.

​
Removing collaborators

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

​
Leaving a project

You can leave a project you collaborate on. Leaving revokes your access to all of the project’s resources, but API keys and resources you created in it keep working after you leave.
  1. Go to Project Settings.
  2. In the Leave project section, select Leave project.
  3. Confirm.
You can also leave from your own row in Settings > Project > Collaborators, or from a project’s three-dot menu in the Organization Settings projects list. Whether you can rejoin depends on your role and the project’s visibility:
  • Organization admins can rejoin anytime.
  • Organization members can rejoin an open project anytime. For closed or private projects, a project admin must add you back. Private projects also stop appearing in your project list after you leave.
  • External collaborators need a project admin to add them back, even if the project is open.
You can’t leave in two cases:
  • Organization members can’t leave the organization’s default project, since all organization members automatically have access to it. External collaborators can leave it.
  • The project’s last admin can’t leave. Make another collaborator an admin first.

​
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.

​
Project API keys

Each project has its own API keys. These keys authenticate API requests and are scoped to the project’s resources.

​
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 single sign-on (SSO) or organization invites. Contact support for help with migration.

​
Next steps

Roles and 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.