Projects Workflow

Projects are the top-level container for your RetainDB data. If your project model is messy, every connector, search result, and dashboard view gets harder to reason about.

Use the Projects page to keep that boundary clean.

What you can do on this page

From /dashboard/projects, you can:

• create a new project
• search existing projects
• sort the list
• open a project-specific dashboard
• edit or delete a project from the actions menu

The page also shows plan-aware project limits so you can see how close you are to your cap.

When to create a new project

Create a separate project when you need a real boundary, for example:

• production vs staging
• separate products or workspaces
• a customer-isolated deployment
• a large internal knowledge domain that should not share retrieval scope

Do not create extra projects just because you have different user ids or multiple sessions. Those belong inside one project unless you need hard separation.

Recommended naming pattern

A naming convention like this stays readable later:

my-app-prod
my-app-staging
internal-docs
support-agent

Short, explicit names are better than clever ones.

Typical workflow

1. Open /dashboard/projects.
2. Click New Project.
3. Give it a name your team will still understand in three months.
4. Add a short description if multiple teams share the org.
5. Open the new project dashboard.
6. Add the first source from there or move to the sources page.

What you see on each project card

Each card is meant to answer four quick questions:

• what is this project called?
• what does it represent?
• does it have a repository or source context attached?
• how much data is already in it?

The list also exposes creation date and document count, which makes it easier to spot stale or empty projects.

What to avoid

Mixing environments

If staging and production share a project, you lose a clean debugging boundary immediately.

Creating throwaway projects for one test

If a temporary experiment should read the same context as your main app, it probably belongs in the existing project.

Using vague names

A name like test, new-project, or demo2 becomes operational debt very quickly.

When a project feels wrong

The most common signals are:

• searches seem to miss data that exists elsewhere
• the sources list is unexpectedly empty
• usage looks split across multiple almost-identical projects

When that happens, fix the project model before debugging retrieval quality.

Next step

Once the project exists, go to sources: add, sync, and troubleshoot to attach real data. If you want the programmatic version of the same workflow, see projects and sources.