Organise with projects
Projects group your apps. How to use them for clients, side projects or teams — and what happens when you delete one.
A project is a folder for related apps. Every app belongs to exactly one, and making projects is free and unlimited, so use as many as suits how you think.
Ask for it
make a project called "Client work" and put this site in it
If you don't ask for one, your agent makes a project on your first deploy and keeps using it. That's fine until you have a dozen things and can't tell them apart.
How people actually use them
| You are | A project per |
|---|---|
| An agency or freelancer | Client |
| Someone with a lot of side projects | Side project |
| A small team | Product, or environment (acme-staging, acme-live) |
| Just tinkering | One project called whatever, forever |
Apps in different projects are entirely independent — separate addresses, separate access lists, separate everything. There's no shared configuration between them, and no inheritance to reason about.
Seeing what you have
list everything I have on agenthost
Your agent can list projects, then the apps in each, with their addresses and status. This is the fastest way back into a mess you made three months ago.
Renaming
rename that project to "Acme Corp"
The display name changes; the underlying slug does not, so nothing that's live is disturbed.
Deleting
Deleting a project takes every app inside it
There's no confirmation step beyond the one your agent gives you, and no undo. Ask what's in a project before deleting it — "what's in the Client work project?" — especially if it's old enough that you don't remember.
See Take something down.
Under the hood
A project gets a URL-safe slug derived from its name, made unique within your organization, and that slug is what the hosting backend groups the apps under. Renaming doesn't regenerate it, which is why existing URLs keep working.
Tools: create_project, list_projects, get_project, rename_project, delete_project.