How Cloud is organised

Cloud has few moving parts. Your account holds organizations, an organization holds projects, a project holds services, a service is released through deployments, and what runs is billed to its organization once a month. Knowing which setting belongs to which part saves most of the confusion.

Your account is you, one person, signing in with GitHub or Google. It holds your organizations, and what stays yours in all of them: your SSH keys, your git providers, your notification channels and your backup destinations. Sign in and your Cahaves account covers signing in.

An organization sits above projects. It holds its projects and everything in them, and it has its own bill: its card or invoices, its monthly limit and its statements. A new account names its first organization at its first sign-in, and you can own up to 10, for example one for each company you run. The console works in one at a time, chosen in the switcher at the top of the sidebar. Organizations covers making, switching and renaming them.

Each organization also has a workspace, its own space on the platform that its services run under, which Cloud starts preparing when the organization is created. Until that finishes, the console says "Your workspace is still being prepared." in that organization and offers nothing to create there.

Everything you create belongs to you alone. Another customer's projects, services and logs are not visible to you, and asking the console or the API for one by its id answers as if it did not exist. A project of another of your own organizations answers the same way until you switch to it. An organization has one owner: Cloud has no members, invitations or roles yet.

A project groups the services that make up one product, for example a web application, a background worker and their database. It belongs to the organization the console was in when it was created, and stays there.

• A project's name is 1 to 60 characters.

• Its address in the console, such as /projects/docs-demo, is derived from the name when the project is created, and never changes. Renaming a project changes its name only.

• No two projects of one organization share an address. A name that reduces to an address the organization already has is refused with "You already have a project with that name.", so Shop! is refused while Shop exists.

• A project is deleted only once it holds no services.

A project has no separate environments such as staging or preview. To run a second copy of a product, create a second project. Projects covers creating, finding, renaming and deleting them.

A service is one thing Cloud runs, and it is one of three kinds:

The catalogue's applications (n8n, Hermes Agent and OpenClaw) are applications made from an image, created with their storage and settings in place.

Every service shows its state as a chip, in its project's list and in its own header:

A chip says what Cloud last asked the service to be. What its containers actually did is on the service's Overview: if a container keeps exiting, an alert there says "The engine keeps restarting this service". Service lifecycle covers each state, what moves a service between them, and deleting one.

A deployment builds the service, when it comes from a repository, and releases the result. Each service numbers its own deployments from 1, so Deployment #12 names one release of one service. The Trigger says what started it:

• Manual: somebody pressed Deploy.

• Git push: a push reached the branch a GitHub service follows, and the service deploys on every push.

• Redeploy: Cloud started it to apply a domain change to a compose stack.

A deployment's chip reads Queued, Starting, Deploying, then Done, Failed or Cancelled. A service runs one deployment at a time, and creating a service never deploys it. There is no button that redeploys an older deployment. Deployments covers statuses, cancelling and what happens when an outcome is in doubt.

Each service keeps its own configuration:

• Environment variables, one NAME=value per line, for an application or a compose stack.

• Domains, which give an application or a compose stack an HTTPS address. An application gets one on the platform's domain after it deploys successfully; a compose stack gets one only when you add it.

• Volumes, which keep an application's files across deploys. Without one, anything a container writes to its own disk is gone at the next deploy. A database keeps its data on a volume Cloud manages for it.

• Backups of a database's contents or of an application's volumes.

A database has no domain. Your other services connect to it on its Internal address, shown on the Connection card of its Overview; the form that creates it says "Services in this project reach it on port" followed by its port. Its password is what protects it, so keep the password secret and change it if it leaks.

Every service has a size, from Nano to Extra large, which sets the CPU and memory an application or a database may use and the rate the service is charged at: by the hour, or for a database, by the GB of data it holds. The size picker and the Order summary show each size's current figures and rate. Sizes and replicas covers what each size applies to.

A service is charged in one of two capacity pools, and the pool decides the rate:

• Shared: applications and databases.

• Dedicated: every compose stack, from Small up. Cloud cannot hold a compose stack's containers to a size's limits the way it holds an application's, so a stack is always charged at the dedicated rate.

The pool is shown as Pool on the service's Overview.

Cloud bills by the month, in US dollars, and bills each organization on its own. Billing, under Settings, shows how the organization the console is in pays, its month so far and every month's statement.

• Every hour, on the hour (UTC), Cloud counts each service's running containers and charges that hour at the service's size and pool. A service with nothing running is not charged, and volumes and backups are not charged on their own.

• Your first nano service, and your first nano database up to its free data, cost nothing and need no card. The allowance is yours rather than each organization's, so it counts your first ones across all your organizations.

• On the 1st of each month, each organization's month before is charged to the card Paddle keeps for it, or invoiced if Cahaves bills that organization that way.

• Each organization's monthly limit refuses new paid work in it that would take its month past the limit, and so does a charge that failed or an invoice past its due date. Neither stops what is running.

Billing explains statements, the monthly limit and paying.