The Cloud Noce service model

Cloud Noce is organized into accounts, projects, environments and services. Understanding these four levels resolves most questions about the dashboard and CLI.

Accounts, projects and environments

Your account is your sign-in identity. A project is a product’s operational boundary: it contains members, environments, services, add-ons, domains and audit records. Every project has a production environment and can also have staging and preview environments. Variables and releases belong to environments, so a staging change should not accidentally change production.

One service model

In the current version, “applications” and “containers” are not separate products. Every workload is a service, with the same management flow for status, logs, variables, domains, builds and releases. A service can come from GitHub/GitLab, a local folder, a Docker image or a marketplace template.

Access type is independent of the source:

HTTP: a website or API with a URL and HTTPS;
TCP: a raw protocol such as a database or broker, with an endpoint and port;
Private: communication between internal services only;
Cron: short scheduled runs without a public endpoint.

Regular services are always on. Stop is an explicit action; Start runs the service again. Incoming requests do not automatically wake a stopped service.

Builds and releases

A build is the immutable output of a version of your source code. A release activates that build together with a configuration snapshot in an environment. Rollback redeploys an existing build without rebuilding it. Promote moves the current build to another environment.

Variable precedence

When several levels define the same key, the value closest to the service wins. From lowest to highest priority:

Shared project secret;
Environment variable;
Add-on connection variable;
The service’s own variable or env value.

Build-time variables are available while building the image; runtime variables are injected only when the container runs. Secret values are masked after saving.

Persistent data

Do not assume files in a container’s temporary filesystem persist. Store important data in a volume or an add-on. A volume survives restarts but is not a backup. Keep backups outside the service itself and test recovery.