Application catalogue
Application catalogue
Applications Cloud creates ready to use, how their environment is filled, and finishing their setup.
Updated
The catalogue holds applications someone else wrote, which Cloud creates ready to use: a pinned image, the right port and command, a volume for their state, and the secrets they need generated for you. Once created, each is an ordinary application service.
Create one
On a project, press Add a service. The Services group at the bottom of the page lists the catalogue; press Create on the application you want. The form is titled after it, such as "Create n8n", and asks for:
Name: up to 40 characters. It starts as the application's name in lowercase, with hyphens for spaces:
n8n,hermes-agent,openclaw.Size: the list starts at Small, the smallest size each of the three runs at. A smaller size sent through the API is refused with "n8n needs small or larger." and the same sentence for the others.
One field for each value the application asks for. Hermes Agent and OpenClaw ask for an OpenRouter key, which is optional: "Leave blank to set it later in the service's environment." n8n asks for nothing.
Automatic backup: Daily, Weekly, Monthly or No automatic backup for the application's volume. Daily is the default where platform backup storage is available.
Press Create service. The browser opens the new service's page. Cloud has attached a volume named State at the application's data path, so the first container already writes its state somewhere that outlives it. Nothing runs until you press Deploy.
If the Services group fails to load, the page shows "Cloud's own services did not load" and "Applications and databases are still here; reload the page to try that group again."
Its environment
A catalogue application's environment is filled from four kinds of value:
| Kind | Filled by | Saved in the service's environment |
|---|---|---|
| Generated | Cloud, once, at creation, such as a password | Yes |
| Asked | Your answer on the create form | Yes, when you gave one |
| Fixed | The catalogue entry, each time the environment is sent | No |
| Domain | The service's address, each time the environment is sent | No |
Generated and asked values are written into the service's environment when it is created, so the Environment section shows them, credentials included. Fixed and domain values are computed each time and never saved. To use a different value for one of them, set the same name yourself on the Environment section; yours is used from then on.
Domain values wait for an address. Until the service has a domain, they are not sent at all and the application's own default stands. After that they use the service's platform domain, or its oldest custom domain when it has no platform domain. When a domain is added, renamed or removed, Cloud sends a running service its new address and restarts it. Of the three entries, only n8n has domain values.
When setup does not finish
The service's Overview shows Setup did not finish with one of these sentences:
| Sentence | What happened |
|---|---|
| "Cloud could not attach the storage this application keeps its data in: … Attach it from the service's storage before deploying, or the application loses everything it stores each time its container is replaced." | The volume could not be attached when the service was created. The sentence names the path |
| "Cloud could not finish setting this application up. Try again." | OpenClaw's first-run files could not be written into its container |
| "Cloud could not finish setting this application up: it is not running, so there is nothing to write its files into. Start the service, then try again." | OpenClaw's first deploy finished, but no container was running to write into |
Press Try again. Cloud attaches any volume still missing, then writes the first-run files if they are still outstanding, and answers "Setup finished." when nothing is left. The service is kept either way, so you can read what happened and retry. Catalogue setup did not finish goes through each case.
Fix a missing volume before the first deploy
Deployed without its volume, the application keeps its state inside the container, and loses it the next time the container is replaced.
Nothing is locked
A catalogue application is an ordinary application from the moment it exists. Its environment, start command, volumes and domains change the same way as any other service's, and nothing refuses a change because it came from the catalogue. If an entry is later withdrawn from the catalogue, services made from it keep running.
The image is the one exception: it is fixed for the life of the service, like any service created from an image. A newer release in the catalogue reaches new services, not the ones you already run.
Two rules worth knowing
A start command runs with no shell. It is split on spaces and run directly, so quotes, pipes and && reach the program as literal words. Build settings explains the consequences.
Files Cloud writes into a container are owned by root and readable by every process in it. The platform offers no way to set another owner or mode. A process that does not run as root cannot overwrite such a file in place; it can only replace it by renaming a new file over it, in a directory it owns. A secret placed in one of these files is readable by any process inside that container.
Delete one
A catalogue application is deleted like any service, from Settings under Delete this service. Cloud refuses while it still has its domain or its volume: remove the domain from Domains, then the State volume from Storage, and delete it after that. Removing the volume attachment does not erase its data, but the console cannot attach that volume again. Volumes explains why, and Delete refused lists the refusals.