Projects and applications

How work is organised — projects, environments, applications — and every setting an application carries.

The hierarchy

Organization
└── Project              a product, or a customer
    └── Environment      production, staging, whatever you name
        └── Application  one deployable thing, on one server

A project is created with a name and a slug, and comes with one environment named production.
An environment exists so the same application can have a staging copy without a second project. Applications are scoped to one.
An application belongs to one environment and runs on one server. On a self-hosted install there is only one server and it is chosen for you.

Everything belongs to an organization, and every read and write is scoped to the organization on your session. See organizations and members.

Creating an application

The one value the platform cannot infer is the port your container listens on. It is what the health gate connects to and what the router forwards to, and everything else has a default.

Settings

Setting	Default	Range	What it does
`exposedPort`	—	1–65535	The container port that faces traffic. Required.
`exposedServiceName`	Inferred	≤ 63 chars	Which service in a multi-service compose file faces the world. Inferred when the file declares exactly one.
`composePath`	Detected	≤ 255 chars	Overrides detection. When set, only this file is considered.
`dockerfilePath`	Detected	≤ 255 chars	Same, for a `Dockerfile`.
`contextPath`	Source root	≤ 255 chars	The build context.
`healthTimeoutSeconds`	60	5–900	How long the health gate retries before the deployment fails.
`cpuLimit`	None	0.1–64	Written into the rendered compose file as `cpus`.
`memoryLimitMb`	None	64–131072	Written as `mem_limit`.
`imageRetentionCount`	3	1–20	How many previous images are kept. Each one is a rollback target and a full image on disk.
`deployStrategy`	`RECREATE`	`RECREATE` \| `BLUE_GREEN`	See deployments and rollback.

buildType is not a setting — it is detected at the first deployment. See build types.

Status

An application is in one of five states:

Status	Meaning
`NEW`	Created, never deployed.
`DEPLOYING`	A deployment is in flight.
`RUNNING`	Containers are up and the last deployment succeeded.
`STOPPED`	Stopped on purpose, through the portal.
`FAILED`	The last deployment failed. The previous version, if there was one, is still running.

Lifecycle

Start, stop, and restart are three explicit actions on the application. They run through the lifecycle queue, which has a concurrency of 4 — they are cheap compared to a build.

Stopping an application stops its containers. It does not delete its volumes, its images, its deployment history, or its domains.

Deleting an application removes its compose project and its containers. Deleting a server refuses while anything is still deployed to it — that refusal is deliberate, because the alternative is orphaning containers on a machine the portal no longer lists.