> For the complete documentation index, see [llms.txt](https://docs.kinesis.network/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.kinesis.network/getting-started/running-llms-with-kinesis-network/creating-a-project.md).

# Create a project

Create a project in your organization and choose who can access it.

A project groups related apps inside an organization: a service and its workers, an experiment, or a team's environment. The organization owns the project and pays for its apps. The person who creates it is its **creator**.

## Create the project

1. Sign in to the [portal](https://portal.kinesis.network). Choose the intended organization from the account menu at the bottom of the sidebar.
2. Open **Projects** and choose **Create Project**. You need an Admin or Developer organization role.
3. Give it a useful name, such as `inference-staging`, and choose **Private** or **Everyone at your organization**. Private is the default.
4. Create the project, then choose a gallery template or configure your first app.

An organization's Projects URL includes its permanent slug: `/dashboard/<org-slug>/projects`. The list groups private projects you created, organization-wide projects and other accessible private projects by creator. Filter and sort choices are remembered per organization. Inside a project, apps can be filtered by creator and status.

## Work with a team

Private projects are visible to organization admins, their creator and members added through **Share**. Organization-wide projects are visible to all members within their roles. Apps inherit the project's visibility; a member can also be added to just one app.

Admins and the project's creator manage access and visibility. Developers edit accessible apps with Developer access and delete projects/apps they created. Viewers can inspect, with no terminal or secret values. A resource grant never raises an organization role.

Deleting a project also deletes its apps. A Developer must have created every app inside it; otherwise ask an admin. REST and MCP deletion require all apps to be stopped first.

Removing the creator from the organization does not delete the project or stop its apps. See [Members and roles](/organizations/members.md) and [Sharing and visibility](/organizations/sharing.md).

## Move to another organization

An admin of both organizations can use **Move to Another Org** from the project card menu. The preview includes its apps, their grids and the source organization’s servers in those grids. Resolve blockers before confirming. See [Move resources](/organizations/move-resources.md).

## Automate project creation

Use `POST /projects?org=<slug>` with `name` and optional `visibility: "private"` or `"org"`, or MCP `create_project` with an `org` argument. A credential needs `projects:write` and the person must be an Admin or Developer. Keys limited to specific projects cannot create another project.

Use MCP `update_project` to change the name or visibility. The former action name `rename_project` has been replaced. See [Projects API](/api/projects.md).

[Deploy from the App Gallery](/getting-started/running-llms-with-kinesis-network/creating-apps-with-app-gallery.md) · [Create a custom app](/getting-started/running-llms-with-kinesis-network/creating-an-app-from-scratch.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

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

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.kinesis.network/getting-started/running-llms-with-kinesis-network/creating-a-project.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.