A cast-created project is left carrying Coolify's empty default environment #40

New issue

Closed

opened 2026-07-14 16:50:09 +00:00 by dan-claude-bot · 0 comments

dan-claude-bot commented

2026-07-14 16:50:09 +00:00

(Migrated from github.com)

Follow-up to #38 / #39.

POST /projects {name} makes Coolify create the project with its own default environment, named production. Since #39, cast then creates the environment it actually wants (--env, e.g. prod) — so a project cast created from nothing now ends up with two environments, one of them permanently empty:

production   ← Coolify's default. Empty, forever.
prod         ← ours. Everything lives here.

That is precisely the shape that makes an adopted box hard to read later, and we have a live example of the confusion it causes: on the box being migrated away from, the project's production environment is empty and everything runs in staging — "the obvious guess is the wrong one" is a note we had to write down for ourselves.

DELETE /projects/{uuid}/environments/{environment_name_or_uuid} exists in the vendored 4.1.2 spec.

Suggested behaviour

When cast itself created the project in this run (not adopted an existing one), and the default environment is empty, and its name is not the one cast is about to use — delete it. All three conditions matter:

cast created it — never touch a project someone built by hand.
empty — never delete an environment holding resources.
name differs — a project whose --environment legitimately is production must keep it.

Anything else (adopted project, non-empty default, name match) is left exactly as it is.

Alternatively cast could simply use the default environment when it created the project and no --environment was given — but that is worse: it silently adopts Coolify's vocabulary for our environment, which is the collapse --environment exists to prevent, and the name would then be inherited by every future rebuild.

Follow-up to #38 / #39. `POST /projects {name}` makes Coolify create the project **with its own default environment, named `production`**. Since #39, cast then creates the environment it actually wants (`--env`, e.g. `prod`) — so a project cast created from nothing now ends up with **two** environments, one of them permanently empty: ``` production ← Coolify's default. Empty, forever. prod ← ours. Everything lives here. ``` That is precisely the shape that makes an adopted box hard to read later, and we have a live example of the confusion it causes: on the box being migrated away from, the project's `production` environment is empty and everything runs in `staging` — "the obvious guess is the wrong one" is a note we had to write down for ourselves. `DELETE /projects/{uuid}/environments/{environment_name_or_uuid}` exists in the vendored 4.1.2 spec. ## Suggested behaviour When **cast itself created the project in this run** (not adopted an existing one), and the default environment is **empty**, and its name is **not** the one cast is about to use — delete it. All three conditions matter: - *cast created it* — never touch a project someone built by hand. - *empty* — never delete an environment holding resources. - *name differs* — a project whose `--environment` legitimately is `production` must keep it. Anything else (adopted project, non-empty default, name match) is left exactly as it is. Alternatively cast could simply *use* the default environment when it created the project and no `--environment` was given — but that is worse: it silently adopts Coolify's vocabulary for our environment, which is the collapse `--environment` exists to prevent, and the name would then be inherited by every future rebuild.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: heavy-duty/cast#40

No description provided.