Organizations, projects, workloads
The three nouns everything else hangs off, and which one owns what.
Three levels, and that is all
| What it is | What it owns | |
|---|---|---|
| Organization | Your company on klickops | The plan, the bill, the people, and every project below it |
| Project | A box for related workloads | Apps, databases, buckets, scheduled jobs, volumes, and the network rules between them |
| Workload | One running thing | Its own domains, configuration, storage and backups |
There is no fourth level. Anything that looks like one is a facet of a workload: a domain belongs to the app it routes to, a volume to the app that mounts it, a certificate to its domain.
Organizations
The organization is the boundary for everything that is not a running container. Access is granted here, the plan applies here, and the invoice is issued here. Someone added to an organization can see its projects; there is no separate per-project login.
You get one when you sign up. Most people never need a second, and a second one is a real separation: separate bill, separate members, no sharing.
Projects
A project is where you group things that belong together. The useful test is whether they talk to each other: an app and the database it queries belong in one project, because inside a project they reach each other by name over a private network with nothing exposed.
Two consequences worth knowing up front:
- A workload cannot move between projects. Not an app, not a database. Splitting one project into two means recreating things, so it is worth a minute of thought at the start.
- Deleting a project deletes what is inside it. That is the point of the box, and it is the fastest way to clean up an experiment.
Project names are unique inside an organization and nowhere else, so two organizations can both have one called api without coordinating.
Under the hood a project is a Kubernetes namespace with a random name, and every workload in it is ordinary Kubernetes underneath. That matters if you ever want to leave: your resources are plain Kubernetes objects, not a proprietary format, and removing the klickops labels leaves them running.
Workloads
A workload is one running thing you can point at. Today that means an app, a database, a bucket, a scheduled job, or a volume.
Everything you configure hangs off one of them, which is why the handbook has a page per workload rather than a page per setting. If you are looking for where to change something, start from the thing it affects.
Naming
Names are lowercase letters, numbers and hyphens, and they are permanent: renaming a project or a workload is not supported, because the name is the identity other things reference.
Name for what a thing is rather than where it runs. orders-db survives a move from staging to production; prod-db-v2 starts lying the moment anything changes.
Limits
The plan sits on the organization and caps how much of each thing you get: projects, apps, databases, replicas, custom domains, and how much CPU, memory and disk a project may use in total.
Limits are enforced when you create something, not when the bill arrives, so hitting one is an error on the form rather than a surprise later. The current numbers for each plan are on the Plans page in the product.