feat: cast — the Coolify executor, extracted from the infra state repo
Public tool, private state. cast holds no hostnames, no bindings, no
secrets: it joins a product repo's .infra/ manifest with a state directory
you point it at, and makes Coolify match.
Extracted from heavy-duty/infra, which was half tool and half state — the
inconsistency that made it impossible to say whether "infra" named a CLI
or a runbook. rig builds the boxes; cast fills them; infra is what they
are filled with.
Two changes were required to make it genuinely stateless and publishable:
- The implicit cwd contract (environments.yaml / secrets/ / .coolify.env
resolved against the working directory, silently reading the wrong file
from the wrong place) is now an explicit --state <dir> / $CAST_STATE.
- BANNED_IN_PROD — a hardcoded list of one product's ALLOW_* flags, the
only product knowledge in the executor — becomes the generic, operator-
owned environments.<env>.forbidden_var_patterns. The guard now lives in
private state, so a product-side change cannot lower its own guard, and
it is a pattern rather than a list, so it catches unforeseen siblings.
Age identities resolve as $CAST_AGE_KEY_FILE_<ENV> then
~/.config/cast/age-<env>.key — which is the entire attended-vs-unattended
apply mechanism, with no environment names known to the tool.
Instance identity (org names, the GitHub App name, founder domains) is out
of the fixtures and out of register-github-app.sh, which took APP_NAME and
ORG as arguments rather than baking them in.
69 tests green; bin/cast + curl installer mirror rig's shape.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-11 12:25:44 +00:00
|
|
|
import { describe, expect, it } from "vitest";
|
fix(apply): refuse to write the generated-secret placeholder over a live value
The bootstrap is two-pass and only the first pass was ever safe to repeat.
The store holds `pending-coolify-generated` for a provider-generated secret;
the first apply sends it, Coolify creates the Postgres/Redis and replaces it
with the real URL. From that moment the store is known-wrong — and `diff` and
`apply` had never heard of the literal cast itself invented to say so.
`diff` printed `secret DATABASE_URL differs`, which is word for word what a
legitimate rotation prints, and `apply` stood ready to PATCH the placeholder
back over the live URL and redeploy every consumer onto it. Coolify's bulk env
endpoint is a plain upsert (create_bulk_envs, v4.1.2: an existing key is found
and its value overwritten), so nothing on the far side stopped it either.
- diffEnv gives the placeholder its own state, `placeholder-conflict`, when the
store holds it and the live resource holds anything else. Live-also-
placeholder, absent live, and the create path are unchanged.
- renderDiff says it in words no rotation prints, and counts it in the summary.
- applyPlan REFUSES on it, before any resource is touched — same fail-closed
shape as the not-updatable refusal. The message names the key and the
resource, never the live value, and points at the remedy (#48).
Keyed on the store's VALUE, not the manifest's `generated_secrets:` list: that
list names store refs (DATABASE_URL_PROD) while an env diff is keyed by env var
key (DATABASE_URL). Matching the list against these keys would have sailed past
the very case that motivated the issue.
Closes #47.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-14 22:24:09 +00:00
|
|
|
import { GENERATED_PLACEHOLDER } from "../src/capture.js";
|
|
|
|
|
import { computeDiff, placeholderConflicts, renderDiff } from "../src/diff.js";
|
feat: cast — the Coolify executor, extracted from the infra state repo
Public tool, private state. cast holds no hostnames, no bindings, no
secrets: it joins a product repo's .infra/ manifest with a state directory
you point it at, and makes Coolify match.
Extracted from heavy-duty/infra, which was half tool and half state — the
inconsistency that made it impossible to say whether "infra" named a CLI
or a runbook. rig builds the boxes; cast fills them; infra is what they
are filled with.
Two changes were required to make it genuinely stateless and publishable:
- The implicit cwd contract (environments.yaml / secrets/ / .coolify.env
resolved against the working directory, silently reading the wrong file
from the wrong place) is now an explicit --state <dir> / $CAST_STATE.
- BANNED_IN_PROD — a hardcoded list of one product's ALLOW_* flags, the
only product knowledge in the executor — becomes the generic, operator-
owned environments.<env>.forbidden_var_patterns. The guard now lives in
private state, so a product-side change cannot lower its own guard, and
it is a pattern rather than a list, so it catches unforeseen siblings.
Age identities resolve as $CAST_AGE_KEY_FILE_<ENV> then
~/.config/cast/age-<env>.key — which is the entire attended-vs-unattended
apply mechanism, with no environment names known to the tool.
Instance identity (org names, the GitHub App name, founder domains) is out
of the fixtures and out of register-github-app.sh, which took APP_NAME and
ORG as arguments rather than baking them in.
69 tests green; bin/cast + curl installer mirror rig's shape.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-11 12:25:44 +00:00
|
|
|
|
|
|
|
|
const desiredApp = {
|
|
|
|
|
kind: "application" as const,
|
|
|
|
|
name: "core-api",
|
|
|
|
|
fields: { build_pack: "nixpacks", domains: ["https://api.example.com"] },
|
|
|
|
|
env: {
|
|
|
|
|
vars: {
|
|
|
|
|
PORT: { value: "3000", secret: false },
|
|
|
|
|
MAILGUN_KEY: { value: "mk-123", secret: true },
|
|
|
|
|
},
|
|
|
|
|
},
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
describe("computeDiff", () => {
|
|
|
|
|
it("plans a create when live is missing", () => {
|
|
|
|
|
const r = computeDiff([desiredApp], [], "full");
|
|
|
|
|
expect(r.changes).toHaveLength(1);
|
|
|
|
|
expect(r.changes[0].op).toBe("create");
|
|
|
|
|
expect(r.clean).toBe(false);
|
|
|
|
|
});
|
|
|
|
|
it("is clean when live matches", () => {
|
|
|
|
|
const r = computeDiff(
|
|
|
|
|
[desiredApp],
|
|
|
|
|
[
|
|
|
|
|
{
|
|
|
|
|
kind: "application",
|
|
|
|
|
name: "core-api",
|
|
|
|
|
uuid: "u1",
|
|
|
|
|
fields: { ...desiredApp.fields },
|
|
|
|
|
env: { PORT: "3000", MAILGUN_KEY: "mk-123" },
|
|
|
|
|
},
|
|
|
|
|
],
|
|
|
|
|
"full",
|
|
|
|
|
);
|
|
|
|
|
expect(r.clean).toBe(true);
|
|
|
|
|
});
|
|
|
|
|
it("marks build_pack drift as non-updatable", () => {
|
|
|
|
|
const r = computeDiff(
|
|
|
|
|
[desiredApp],
|
|
|
|
|
[
|
|
|
|
|
{
|
|
|
|
|
kind: "application",
|
|
|
|
|
name: "core-api",
|
|
|
|
|
uuid: "u1",
|
|
|
|
|
fields: { build_pack: "static", domains: desiredApp.fields.domains },
|
|
|
|
|
env: { PORT: "3000", MAILGUN_KEY: "mk-123" },
|
|
|
|
|
},
|
|
|
|
|
],
|
|
|
|
|
"full",
|
|
|
|
|
);
|
|
|
|
|
expect(r.changes[0].fieldDiffs).toEqual([
|
|
|
|
|
{
|
|
|
|
|
field: "build_pack",
|
|
|
|
|
desired: "nixpacks",
|
|
|
|
|
live: "static",
|
|
|
|
|
updatable: false,
|
|
|
|
|
},
|
|
|
|
|
]);
|
|
|
|
|
});
|
|
|
|
|
it("full mode diffs env; structural mode does not", () => {
|
|
|
|
|
const live = [
|
|
|
|
|
{
|
|
|
|
|
kind: "application" as const,
|
|
|
|
|
name: "core-api",
|
|
|
|
|
uuid: "u1",
|
|
|
|
|
fields: { ...desiredApp.fields },
|
|
|
|
|
env: { PORT: "3000", MAILGUN_KEY: "OLD", EXTRA: "x" },
|
|
|
|
|
},
|
|
|
|
|
];
|
|
|
|
|
const full = computeDiff([desiredApp], live, "full");
|
|
|
|
|
expect(full.changes[0].envDiffs).toEqual([
|
|
|
|
|
{ key: "MAILGUN_KEY", state: "change", secret: true },
|
|
|
|
|
{ key: "EXTRA", state: "remove-candidate", secret: false },
|
|
|
|
|
]);
|
|
|
|
|
expect(computeDiff([desiredApp], live, "structural").clean).toBe(true);
|
|
|
|
|
});
|
|
|
|
|
it("reports orphans, never plans deletion", () => {
|
|
|
|
|
const r = computeDiff(
|
|
|
|
|
[],
|
|
|
|
|
[{ kind: "service", name: "old-thing", uuid: "u9", fields: {} }],
|
|
|
|
|
"full",
|
|
|
|
|
);
|
|
|
|
|
expect(r.changes).toHaveLength(0);
|
|
|
|
|
expect(r.orphans).toEqual([
|
|
|
|
|
{ kind: "service", name: "old-thing", uuid: "u9" },
|
|
|
|
|
]);
|
|
|
|
|
expect(r.clean).toBe(false);
|
|
|
|
|
});
|
|
|
|
|
});
|
|
|
|
|
|
fix(apply): refuse to write the generated-secret placeholder over a live value
The bootstrap is two-pass and only the first pass was ever safe to repeat.
The store holds `pending-coolify-generated` for a provider-generated secret;
the first apply sends it, Coolify creates the Postgres/Redis and replaces it
with the real URL. From that moment the store is known-wrong — and `diff` and
`apply` had never heard of the literal cast itself invented to say so.
`diff` printed `secret DATABASE_URL differs`, which is word for word what a
legitimate rotation prints, and `apply` stood ready to PATCH the placeholder
back over the live URL and redeploy every consumer onto it. Coolify's bulk env
endpoint is a plain upsert (create_bulk_envs, v4.1.2: an existing key is found
and its value overwritten), so nothing on the far side stopped it either.
- diffEnv gives the placeholder its own state, `placeholder-conflict`, when the
store holds it and the live resource holds anything else. Live-also-
placeholder, absent live, and the create path are unchanged.
- renderDiff says it in words no rotation prints, and counts it in the summary.
- applyPlan REFUSES on it, before any resource is touched — same fail-closed
shape as the not-updatable refusal. The message names the key and the
resource, never the live value, and points at the remedy (#48).
Keyed on the store's VALUE, not the manifest's `generated_secrets:` list: that
list names store refs (DATABASE_URL_PROD) while an env diff is keyed by env var
key (DATABASE_URL). Matching the list against these keys would have sailed past
the very case that motivated the issue.
Closes #47.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-14 22:24:09 +00:00
|
|
|
// The second pass of the two-pass bootstrap (#47). The store holds the literal
|
|
|
|
|
// `pending-coolify-generated` for a provider-generated secret; once the first
|
|
|
|
|
// apply has run, Coolify holds the real one. Every fixture here is that state.
|
|
|
|
|
const REAL_URL = "postgres://real:secret@db:5432/app";
|
|
|
|
|
const generatedApp = {
|
|
|
|
|
kind: "application" as const,
|
|
|
|
|
name: "core-api",
|
|
|
|
|
fields: {},
|
|
|
|
|
env: {
|
|
|
|
|
vars: {
|
|
|
|
|
// The env var KEY. In the real manifest the store REF behind it is
|
|
|
|
|
// `DATABASE_URL_PROD` — the two differ, which is why the guard is keyed
|
|
|
|
|
// on the store's VALUE and not on the `generated_secrets:` name list.
|
|
|
|
|
DATABASE_URL: { value: GENERATED_PLACEHOLDER, secret: true },
|
|
|
|
|
PORT: { value: "3000", secret: false },
|
|
|
|
|
},
|
|
|
|
|
},
|
|
|
|
|
};
|
|
|
|
|
const liveGenerated = (env: Record<string, string>) => [
|
|
|
|
|
{
|
|
|
|
|
kind: "application" as const,
|
|
|
|
|
name: "core-api",
|
|
|
|
|
uuid: "u1",
|
|
|
|
|
fields: {},
|
|
|
|
|
env,
|
|
|
|
|
},
|
|
|
|
|
];
|
|
|
|
|
|
|
|
|
|
describe("computeDiff generated-secret placeholder", () => {
|
|
|
|
|
it("flags a placeholder-in-store vs real-value-live as a conflict, not a change", () => {
|
|
|
|
|
const r = computeDiff(
|
|
|
|
|
[generatedApp],
|
|
|
|
|
liveGenerated({ DATABASE_URL: REAL_URL, PORT: "3000" }),
|
|
|
|
|
"full",
|
|
|
|
|
);
|
|
|
|
|
expect(r.changes[0].envDiffs).toEqual([
|
|
|
|
|
{ key: "DATABASE_URL", state: "placeholder-conflict", secret: true },
|
|
|
|
|
]);
|
|
|
|
|
expect(r.clean).toBe(false);
|
|
|
|
|
expect(placeholderConflicts(r)).toEqual([
|
|
|
|
|
{ kind: "application", name: "core-api", key: "DATABASE_URL" },
|
|
|
|
|
]);
|
|
|
|
|
});
|
|
|
|
|
it("is clean when the live value is the placeholder too (first apply landed, resource not created yet)", () => {
|
|
|
|
|
const r = computeDiff(
|
|
|
|
|
[generatedApp],
|
|
|
|
|
liveGenerated({ DATABASE_URL: GENERATED_PLACEHOLDER, PORT: "3000" }),
|
|
|
|
|
"full",
|
|
|
|
|
);
|
|
|
|
|
expect(r.clean).toBe(true);
|
|
|
|
|
expect(placeholderConflicts(r)).toEqual([]);
|
|
|
|
|
});
|
|
|
|
|
it("is a plain add — not a conflict — when the var is absent live (the FIRST apply's path)", () => {
|
|
|
|
|
const r = computeDiff(
|
|
|
|
|
[generatedApp],
|
|
|
|
|
liveGenerated({ PORT: "3000" }),
|
|
|
|
|
"full",
|
|
|
|
|
);
|
|
|
|
|
expect(r.changes[0].envDiffs).toEqual([
|
|
|
|
|
{ key: "DATABASE_URL", state: "add", secret: true },
|
|
|
|
|
]);
|
|
|
|
|
expect(placeholderConflicts(r)).toEqual([]);
|
|
|
|
|
});
|
|
|
|
|
it("is a plain add on a create — Coolify replaces the placeholder when it makes the resource", () => {
|
|
|
|
|
const r = computeDiff([generatedApp], [], "full");
|
|
|
|
|
expect(r.changes[0].op).toBe("create");
|
|
|
|
|
expect(r.changes[0].envDiffs).toContainEqual({
|
|
|
|
|
key: "DATABASE_URL",
|
|
|
|
|
state: "add",
|
|
|
|
|
secret: true,
|
|
|
|
|
});
|
|
|
|
|
expect(placeholderConflicts(r)).toEqual([]);
|
|
|
|
|
});
|
|
|
|
|
it("leaves an ordinary secret rotation a plain change", () => {
|
|
|
|
|
const r = computeDiff(
|
|
|
|
|
[desiredApp],
|
|
|
|
|
[
|
|
|
|
|
{
|
|
|
|
|
kind: "application" as const,
|
|
|
|
|
name: "core-api",
|
|
|
|
|
uuid: "u1",
|
|
|
|
|
fields: { ...desiredApp.fields },
|
|
|
|
|
env: { PORT: "3000", MAILGUN_KEY: "mk-OLD" },
|
|
|
|
|
},
|
|
|
|
|
],
|
|
|
|
|
"full",
|
|
|
|
|
);
|
|
|
|
|
expect(r.changes[0].envDiffs).toEqual([
|
|
|
|
|
{ key: "MAILGUN_KEY", state: "change", secret: true },
|
|
|
|
|
]);
|
|
|
|
|
expect(placeholderConflicts(r)).toEqual([]);
|
|
|
|
|
});
|
|
|
|
|
// A non-secret template literal that happens to read `pending-coolify-generated`
|
|
|
|
|
// came from the template, not the store — nothing generated it, and writing it
|
|
|
|
|
// is what the manifest asked for.
|
|
|
|
|
it("does not flag a non-secret var whose literal value happens to be the placeholder", () => {
|
|
|
|
|
const r = computeDiff(
|
|
|
|
|
[
|
|
|
|
|
{
|
|
|
|
|
kind: "application" as const,
|
|
|
|
|
name: "core-api",
|
|
|
|
|
fields: {},
|
|
|
|
|
env: {
|
|
|
|
|
vars: { NOTE: { value: GENERATED_PLACEHOLDER, secret: false } },
|
|
|
|
|
},
|
|
|
|
|
},
|
|
|
|
|
],
|
|
|
|
|
liveGenerated({ NOTE: "something-else" }),
|
|
|
|
|
"full",
|
|
|
|
|
);
|
|
|
|
|
expect(r.changes[0].envDiffs).toEqual([
|
|
|
|
|
{ key: "NOTE", state: "change", secret: false },
|
|
|
|
|
]);
|
|
|
|
|
expect(placeholderConflicts(r)).toEqual([]);
|
|
|
|
|
});
|
|
|
|
|
it("is invisible to a structural diff, which reads no env at all", () => {
|
|
|
|
|
const r = computeDiff(
|
|
|
|
|
[generatedApp],
|
|
|
|
|
liveGenerated({ DATABASE_URL: REAL_URL }),
|
|
|
|
|
"structural",
|
|
|
|
|
);
|
|
|
|
|
expect(placeholderConflicts(r)).toEqual([]);
|
|
|
|
|
expect(r.clean).toBe(true);
|
|
|
|
|
});
|
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
describe("renderDiff generated-secret placeholder", () => {
|
|
|
|
|
it("says it in words no rotation prints, and never prints the live value", () => {
|
|
|
|
|
const out = renderDiff(
|
|
|
|
|
computeDiff(
|
|
|
|
|
[generatedApp],
|
|
|
|
|
liveGenerated({ DATABASE_URL: REAL_URL, PORT: "3000" }),
|
|
|
|
|
"full",
|
|
|
|
|
),
|
|
|
|
|
);
|
|
|
|
|
expect(out).toContain(
|
|
|
|
|
"secret DATABASE_URL: store holds the generated-secret PLACEHOLDER, live holds a real value — apply would OVERWRITE it",
|
|
|
|
|
);
|
|
|
|
|
// The old line — the one a rotation prints — must NOT be what this reports.
|
|
|
|
|
expect(out).not.toContain("secret DATABASE_URL differs");
|
|
|
|
|
// Loud in the tail as well: the summary is the line read before typing apply.
|
|
|
|
|
expect(out).toContain(
|
|
|
|
|
"1 generated-secret PLACEHOLDER conflict(s) — apply will REFUSE",
|
|
|
|
|
);
|
|
|
|
|
// Names the key, never the value — capture's rule (a secret printed to a
|
|
|
|
|
// terminal is a secret in a scrollback buffer).
|
|
|
|
|
expect(out).not.toContain(REAL_URL);
|
|
|
|
|
expect(out).not.toContain("real:secret");
|
|
|
|
|
});
|
|
|
|
|
});
|
|
|
|
|
|
feat: place a resource on a destination — and a state file that can say which (#21)
A destination is the Docker network a resource is created on. cast never sent
one, so everything landed on the server's default — invisible and harmless while
each server hosts one project, and neither the moment a server hosts two.
The state file had nowhere to say otherwise, either. A destination is scoped
project × environment, and `environments.<env>` is scoped by environment alone:
a `destination:` key there would mean "one network shared by every project in
this environment", which is the isolation it is meant to provide, inverted.
So:
- `environments.<env>.projects.<repo>` — per-project state, keyed by repo, full
`<org>/<repo>` slug first with a bare-`<repo>` fallback, exactly like
`github_apps`. It carries `destination_uuid` and `smoke_target`.
- `smoke_target` moves there. It was state-file-scoped: it named ONE project's
app (`core`) from a key that could not tell two projects apart — or even prod's
app from staging's. The old key is still read (with a warning), so an unmigrated
state file keeps smoking, and `cast smoke` now takes an optional `<org>/<repo>`.
- `apply` sends `destination_uuid` on create, for applications, databases and
services alike — Coolify runs identical destination logic in all three.
The API turns out to be worse than the issue assumed, in a way that changes what
"diff should compare the destination" can honestly mean. Verified against
coollabsio/coolify v4.1.2 (routes/api.php + the three Api controllers), and
written up in reference/README.md:
- There is NO destinations API. Zero routes. A destination cannot be listed, read
or resolved by name — only a raw UUID from the UI identifies one, exactly as
with `s3_destination`. Hence `destination_uuid:` and not `destination:`.
- The field is WRITE-ONLY. Coolify takes `destination_uuid` on write and returns
`destination_id` (an integer PK) on read, with nothing mapping between them.
- On a server with >1 destination, a create that OMITS it is a hard 400. So cast
could not deploy onto a shared box at all — it did not silently misplace there,
it simply failed. On a single-destination server the uuid is ignored entirely
and never validated, so a wrong one is invisible until a second one exists.
A declared UUID therefore cannot be verified against the resource it was sent
for — by cast or by anything else. Diffing it as a field would compare a UUID to
an int and report drift that never clears, so it is reported rather than compared,
and the limit is stated out loud: every diff that declares a destination says it
did not verify it. Silence would make an unverified setting read as a verified
one, which is the failure shape #12/#14/#17/#18 are all about.
What IS comparable is the live side to itself. `diff` groups live resources by the
`destination_id` Coolify does report, and a project whose resources do not all
share one network is drift — non-clean, both sides named, and never repaired
(apply moves nothing between networks). That catches the thing actually worth
catching, including on a box whose destinations were made by hand.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-13 19:31:02 +00:00
|
|
|
// The destination can never be diffed the way a field is: Coolify 4.1.2 takes
|
|
|
|
|
// destination_uuid on write and returns destination_id on read, with nothing
|
|
|
|
|
// mapping between them. So it is REPORTED rather than compared — and the one
|
|
|
|
|
// thing that IS comparable (a project's live resources against each other)
|
|
|
|
|
// carries the check that matters.
|
|
|
|
|
//
|
|
|
|
|
// Placement is measured against the live side ALONE, so these fixtures pair each
|
|
|
|
|
// live resource with a matching desired one: otherwise every resource is an
|
|
|
|
|
// orphan, and `clean` would be false for reasons that have nothing to do with
|
|
|
|
|
// the destination.
|
|
|
|
|
const want = (name: string) => ({
|
|
|
|
|
kind: "application" as const,
|
|
|
|
|
name,
|
|
|
|
|
fields: {},
|
|
|
|
|
});
|
|
|
|
|
const got = (name: string, destinationId?: number) => ({
|
|
|
|
|
kind: "application" as const,
|
|
|
|
|
name,
|
|
|
|
|
uuid: `u-${name}`,
|
|
|
|
|
fields: {},
|
|
|
|
|
destinationId,
|
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
describe("computeDiff placement", () => {
|
|
|
|
|
it("is not split when every resource shares one destination", () => {
|
|
|
|
|
const r = computeDiff(
|
|
|
|
|
[want("a"), want("b")],
|
|
|
|
|
[got("a", 3), got("b", 3)],
|
|
|
|
|
"structural",
|
|
|
|
|
);
|
|
|
|
|
expect(r.placement.split).toBe(false);
|
|
|
|
|
expect(r.placement.groups).toEqual([
|
|
|
|
|
{ destinationId: 3, resources: ["application a", "application b"] },
|
|
|
|
|
]);
|
|
|
|
|
expect(r.clean).toBe(true);
|
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
// A project whose resources straddle two networks is a project whose
|
|
|
|
|
// isolation is broken — drift, not silence. Same disposition as an orphan:
|
|
|
|
|
// reported, counted, never repaired.
|
|
|
|
|
it("reports a split project as drift, and is not clean", () => {
|
|
|
|
|
const r = computeDiff(
|
|
|
|
|
[want("a"), want("b")],
|
|
|
|
|
[got("a", 3), got("b", 7)],
|
|
|
|
|
"structural",
|
|
|
|
|
);
|
|
|
|
|
expect(r.placement.split).toBe(true);
|
|
|
|
|
expect(r.placement.groups).toEqual([
|
|
|
|
|
{ destinationId: 3, resources: ["application a"] },
|
|
|
|
|
{ destinationId: 7, resources: ["application b"] },
|
|
|
|
|
]);
|
|
|
|
|
expect(r.clean).toBe(false);
|
|
|
|
|
// ...and apply is not offered a way to "fix" it.
|
|
|
|
|
expect(r.changes).toHaveLength(0);
|
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
// A resource Coolify reports no destination for is no evidence of a split.
|
|
|
|
|
it("ignores resources with no destination rather than grouping them", () => {
|
|
|
|
|
const r = computeDiff(
|
|
|
|
|
[want("a"), want("b")],
|
|
|
|
|
[got("a", 3), got("b")],
|
|
|
|
|
"structural",
|
|
|
|
|
);
|
|
|
|
|
expect(r.placement.split).toBe(false);
|
|
|
|
|
expect(r.placement.groups).toEqual([
|
|
|
|
|
{ destinationId: 3, resources: ["application a"] },
|
|
|
|
|
]);
|
|
|
|
|
expect(r.clean).toBe(true);
|
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
it("carries the declared destination through without comparing it", () => {
|
|
|
|
|
const r = computeDiff([want("a")], [got("a", 3)], "structural", {
|
|
|
|
|
declaredDestination: "dest-abc",
|
|
|
|
|
});
|
|
|
|
|
expect(r.placement.declared).toBe("dest-abc");
|
|
|
|
|
// Declaring one does not make the project dirty — there is nothing to
|
|
|
|
|
// compare it against, and a phantom "update" would never clear.
|
|
|
|
|
expect(r.clean).toBe(true);
|
|
|
|
|
expect(r.changes).toHaveLength(0);
|
|
|
|
|
});
|
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
describe("renderDiff placement", () => {
|
|
|
|
|
it("says out loud that a declared destination was NOT compared", () => {
|
|
|
|
|
const out = renderDiff(
|
|
|
|
|
computeDiff([want("a")], [got("a", 3)], "structural", {
|
|
|
|
|
declaredDestination: "dest-abc",
|
|
|
|
|
}),
|
|
|
|
|
);
|
|
|
|
|
expect(out).toContain("dest-abc");
|
|
|
|
|
expect(out).toMatch(/NOT compared/);
|
|
|
|
|
expect(out).toMatch(/placement: all resources on destination 3/);
|
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
// The whole reason placement is in the report at all: a destination that read
|
|
|
|
|
// back as absent rather than wrong is the failure shape #12/#14/#17/#18 are
|
fix: the first apply against a fresh multi-destination box (#40, #41)
Both of these were found by the same run — the genuinely-from-nothing apply that
#38 was also hiding in, against a box that shares its server with another project.
Neither is a bug in what apply DOES; both are bugs in what it leaves behind and
what it says.
#40 — cast removes the default environment it made Coolify create.
POST /projects hands a new project Coolify's OWN default environment, `production`.
#39 taught apply to create the environment its resources actually name, so a project
cast creates from nothing now ends up carrying two: ours, holding everything, and an
empty `production` that nothing will ever use. That is precisely the shape that makes
a box unreadable later, and we have the live example — on the box being migrated away
from, `production` is empty and everything runs in `staging`, and "the obvious guess
is the wrong one" is a note we had to write down for ourselves. Shipping more of those
is not neutrality.
This is the only delete cast performs, so it argues for itself against apply-never-
deletes: what that rule protects is things cast did not make, and this is a byproduct
of cast's own POST /projects seconds earlier, holding nothing and having never held
anything. Three conditions, jointly, or nothing is touched — cast created the project
in THIS run (never a project someone built by hand), the environment is EMPTY (asked
of Coolify via the details route, the only one that eager-loads resources — not
inferred from the first condition), and its name is NOT ours (an --environment
production keeps its production, since that is where everything is about to live).
Best-effort: a delete that fails is reported and never fails an apply that worked.
#41 — the multi-destination 400 says what to do, and the plan says what it assumed.
A create against a server with more than one destination that names none is rejected
with "Server has multiple destinations and you do not set destination_uuid." — a
message that names neither the remedy nor the file it goes in, arriving at the FIRST
create, after apply has already made the project and the environment.
cast cannot pre-flight it and that half is not fixable: 4.1.2 serves no destinations
API at all, and GET /servers/{uuid} does not carry them either, so a server's
destination COUNT is unknowable until a create has been attempted. The diagnosis is
what is fixable. The 400 is now answered with the failing resource, the server by the
name the operator wrote (not its UUID), the exact path the UUID goes in
(environments.<env>.projects.<org>/<repo>.destination_uuid), the create-time warning —
placement is repaired by delete + recreate, never by a later apply — and Coolify's own
words kept verbatim, so the next person's search still works.
And the assumption behind an undeclared destination is now on screen at the moment it
is made: `placement: server's default destination (none declared)`. This reverses a
judgment cast held explicitly ("a line on every diff that says nothing is how a report
stops being read" — the test it replaces). The line does not say nothing; it says which
network the next create lands on. It stays on a clean run that creates nothing, too,
because the trap is set for projects that are already built: the day their server gains
a second destination, every one of them that declared no destination stops being able
to create, and nothing will have warned them.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-14 17:25:29 +00:00
|
|
|
// about.
|
|
|
|
|
//
|
|
|
|
|
// This test used to assert the opposite — that an undeclared, unsplit box says
|
|
|
|
|
// NOTHING about placement, on the grounds that a line on every diff is how a
|
|
|
|
|
// report stops being read. #41 reversed it. Declaring nothing is not the absence
|
|
|
|
|
// of a placement decision, it is a placement decision: cast sends no
|
|
|
|
|
// destination_uuid and Coolify picks. Leaving that inference in a source comment
|
|
|
|
|
// is what made it invisible until the day it was wrong — a first apply against a
|
|
|
|
|
// multi-destination server, 400ing after the run had already created the project
|
|
|
|
|
// and the environment. It is a fact about what the next create will do, so it is
|
|
|
|
|
// on screen while it is still true.
|
|
|
|
|
it("says out loud that an undeclared placement is the server's default", () => {
|
feat: place a resource on a destination — and a state file that can say which (#21)
A destination is the Docker network a resource is created on. cast never sent
one, so everything landed on the server's default — invisible and harmless while
each server hosts one project, and neither the moment a server hosts two.
The state file had nowhere to say otherwise, either. A destination is scoped
project × environment, and `environments.<env>` is scoped by environment alone:
a `destination:` key there would mean "one network shared by every project in
this environment", which is the isolation it is meant to provide, inverted.
So:
- `environments.<env>.projects.<repo>` — per-project state, keyed by repo, full
`<org>/<repo>` slug first with a bare-`<repo>` fallback, exactly like
`github_apps`. It carries `destination_uuid` and `smoke_target`.
- `smoke_target` moves there. It was state-file-scoped: it named ONE project's
app (`core`) from a key that could not tell two projects apart — or even prod's
app from staging's. The old key is still read (with a warning), so an unmigrated
state file keeps smoking, and `cast smoke` now takes an optional `<org>/<repo>`.
- `apply` sends `destination_uuid` on create, for applications, databases and
services alike — Coolify runs identical destination logic in all three.
The API turns out to be worse than the issue assumed, in a way that changes what
"diff should compare the destination" can honestly mean. Verified against
coollabsio/coolify v4.1.2 (routes/api.php + the three Api controllers), and
written up in reference/README.md:
- There is NO destinations API. Zero routes. A destination cannot be listed, read
or resolved by name — only a raw UUID from the UI identifies one, exactly as
with `s3_destination`. Hence `destination_uuid:` and not `destination:`.
- The field is WRITE-ONLY. Coolify takes `destination_uuid` on write and returns
`destination_id` (an integer PK) on read, with nothing mapping between them.
- On a server with >1 destination, a create that OMITS it is a hard 400. So cast
could not deploy onto a shared box at all — it did not silently misplace there,
it simply failed. On a single-destination server the uuid is ignored entirely
and never validated, so a wrong one is invisible until a second one exists.
A declared UUID therefore cannot be verified against the resource it was sent
for — by cast or by anything else. Diffing it as a field would compare a UUID to
an int and report drift that never clears, so it is reported rather than compared,
and the limit is stated out loud: every diff that declares a destination says it
did not verify it. Silence would make an unverified setting read as a verified
one, which is the failure shape #12/#14/#17/#18 are all about.
What IS comparable is the live side to itself. `diff` groups live resources by the
`destination_id` Coolify does report, and a project whose resources do not all
share one network is drift — non-clean, both sides named, and never repaired
(apply moves nothing between networks). That catches the thing actually worth
catching, including on a box whose destinations were made by hand.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-13 19:31:02 +00:00
|
|
|
const out = renderDiff(
|
|
|
|
|
computeDiff([want("a")], [got("a", 3)], "structural"),
|
|
|
|
|
);
|
fix: the first apply against a fresh multi-destination box (#40, #41)
Both of these were found by the same run — the genuinely-from-nothing apply that
#38 was also hiding in, against a box that shares its server with another project.
Neither is a bug in what apply DOES; both are bugs in what it leaves behind and
what it says.
#40 — cast removes the default environment it made Coolify create.
POST /projects hands a new project Coolify's OWN default environment, `production`.
#39 taught apply to create the environment its resources actually name, so a project
cast creates from nothing now ends up carrying two: ours, holding everything, and an
empty `production` that nothing will ever use. That is precisely the shape that makes
a box unreadable later, and we have the live example — on the box being migrated away
from, `production` is empty and everything runs in `staging`, and "the obvious guess
is the wrong one" is a note we had to write down for ourselves. Shipping more of those
is not neutrality.
This is the only delete cast performs, so it argues for itself against apply-never-
deletes: what that rule protects is things cast did not make, and this is a byproduct
of cast's own POST /projects seconds earlier, holding nothing and having never held
anything. Three conditions, jointly, or nothing is touched — cast created the project
in THIS run (never a project someone built by hand), the environment is EMPTY (asked
of Coolify via the details route, the only one that eager-loads resources — not
inferred from the first condition), and its name is NOT ours (an --environment
production keeps its production, since that is where everything is about to live).
Best-effort: a delete that fails is reported and never fails an apply that worked.
#41 — the multi-destination 400 says what to do, and the plan says what it assumed.
A create against a server with more than one destination that names none is rejected
with "Server has multiple destinations and you do not set destination_uuid." — a
message that names neither the remedy nor the file it goes in, arriving at the FIRST
create, after apply has already made the project and the environment.
cast cannot pre-flight it and that half is not fixable: 4.1.2 serves no destinations
API at all, and GET /servers/{uuid} does not carry them either, so a server's
destination COUNT is unknowable until a create has been attempted. The diagnosis is
what is fixable. The 400 is now answered with the failing resource, the server by the
name the operator wrote (not its UUID), the exact path the UUID goes in
(environments.<env>.projects.<org>/<repo>.destination_uuid), the create-time warning —
placement is repaired by delete + recreate, never by a later apply — and Coolify's own
words kept verbatim, so the next person's search still works.
And the assumption behind an undeclared destination is now on screen at the moment it
is made: `placement: server's default destination (none declared)`. This reverses a
judgment cast held explicitly ("a line on every diff that says nothing is how a report
stops being read" — the test it replaces). The line does not say nothing; it says which
network the next create lands on. It stays on a clean run that creates nothing, too,
because the trap is set for projects that are already built: the day their server gains
a second destination, every one of them that declared no destination stops being able
to create, and nothing will have warned them.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-14 17:25:29 +00:00
|
|
|
expect(out).toMatch(
|
|
|
|
|
/placement: server's default destination \(none declared\)/,
|
|
|
|
|
);
|
|
|
|
|
// ...and the consequence, which is the only part that can hurt: on a server
|
|
|
|
|
// with more than one destination this is not a default, it is a 400.
|
|
|
|
|
expect(out).toMatch(/refuses the create/);
|
|
|
|
|
// Still clean: an undeclared destination is an assumption, not drift.
|
feat: place a resource on a destination — and a state file that can say which (#21)
A destination is the Docker network a resource is created on. cast never sent
one, so everything landed on the server's default — invisible and harmless while
each server hosts one project, and neither the moment a server hosts two.
The state file had nowhere to say otherwise, either. A destination is scoped
project × environment, and `environments.<env>` is scoped by environment alone:
a `destination:` key there would mean "one network shared by every project in
this environment", which is the isolation it is meant to provide, inverted.
So:
- `environments.<env>.projects.<repo>` — per-project state, keyed by repo, full
`<org>/<repo>` slug first with a bare-`<repo>` fallback, exactly like
`github_apps`. It carries `destination_uuid` and `smoke_target`.
- `smoke_target` moves there. It was state-file-scoped: it named ONE project's
app (`core`) from a key that could not tell two projects apart — or even prod's
app from staging's. The old key is still read (with a warning), so an unmigrated
state file keeps smoking, and `cast smoke` now takes an optional `<org>/<repo>`.
- `apply` sends `destination_uuid` on create, for applications, databases and
services alike — Coolify runs identical destination logic in all three.
The API turns out to be worse than the issue assumed, in a way that changes what
"diff should compare the destination" can honestly mean. Verified against
coollabsio/coolify v4.1.2 (routes/api.php + the three Api controllers), and
written up in reference/README.md:
- There is NO destinations API. Zero routes. A destination cannot be listed, read
or resolved by name — only a raw UUID from the UI identifies one, exactly as
with `s3_destination`. Hence `destination_uuid:` and not `destination:`.
- The field is WRITE-ONLY. Coolify takes `destination_uuid` on write and returns
`destination_id` (an integer PK) on read, with nothing mapping between them.
- On a server with >1 destination, a create that OMITS it is a hard 400. So cast
could not deploy onto a shared box at all — it did not silently misplace there,
it simply failed. On a single-destination server the uuid is ignored entirely
and never validated, so a wrong one is invisible until a second one exists.
A declared UUID therefore cannot be verified against the resource it was sent
for — by cast or by anything else. Diffing it as a field would compare a UUID to
an int and report drift that never clears, so it is reported rather than compared,
and the limit is stated out loud: every diff that declares a destination says it
did not verify it. Silence would make an unverified setting read as a verified
one, which is the failure shape #12/#14/#17/#18 are all about.
What IS comparable is the live side to itself. `diff` groups live resources by the
`destination_id` Coolify does report, and a project whose resources do not all
share one network is drift — non-clean, both sides named, and never repaired
(apply moves nothing between networks). That catches the thing actually worth
catching, including on a box whose destinations were made by hand.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-13 19:31:02 +00:00
|
|
|
expect(out).toContain("clean");
|
|
|
|
|
});
|
|
|
|
|
|
fix: the first apply against a fresh multi-destination box (#40, #41)
Both of these were found by the same run — the genuinely-from-nothing apply that
#38 was also hiding in, against a box that shares its server with another project.
Neither is a bug in what apply DOES; both are bugs in what it leaves behind and
what it says.
#40 — cast removes the default environment it made Coolify create.
POST /projects hands a new project Coolify's OWN default environment, `production`.
#39 taught apply to create the environment its resources actually name, so a project
cast creates from nothing now ends up carrying two: ours, holding everything, and an
empty `production` that nothing will ever use. That is precisely the shape that makes
a box unreadable later, and we have the live example — on the box being migrated away
from, `production` is empty and everything runs in `staging`, and "the obvious guess
is the wrong one" is a note we had to write down for ourselves. Shipping more of those
is not neutrality.
This is the only delete cast performs, so it argues for itself against apply-never-
deletes: what that rule protects is things cast did not make, and this is a byproduct
of cast's own POST /projects seconds earlier, holding nothing and having never held
anything. Three conditions, jointly, or nothing is touched — cast created the project
in THIS run (never a project someone built by hand), the environment is EMPTY (asked
of Coolify via the details route, the only one that eager-loads resources — not
inferred from the first condition), and its name is NOT ours (an --environment
production keeps its production, since that is where everything is about to live).
Best-effort: a delete that fails is reported and never fails an apply that worked.
#41 — the multi-destination 400 says what to do, and the plan says what it assumed.
A create against a server with more than one destination that names none is rejected
with "Server has multiple destinations and you do not set destination_uuid." — a
message that names neither the remedy nor the file it goes in, arriving at the FIRST
create, after apply has already made the project and the environment.
cast cannot pre-flight it and that half is not fixable: 4.1.2 serves no destinations
API at all, and GET /servers/{uuid} does not carry them either, so a server's
destination COUNT is unknowable until a create has been attempted. The diagnosis is
what is fixable. The 400 is now answered with the failing resource, the server by the
name the operator wrote (not its UUID), the exact path the UUID goes in
(environments.<env>.projects.<org>/<repo>.destination_uuid), the create-time warning —
placement is repaired by delete + recreate, never by a later apply — and Coolify's own
words kept verbatim, so the next person's search still works.
And the assumption behind an undeclared destination is now on screen at the moment it
is made: `placement: server's default destination (none declared)`. This reverses a
judgment cast held explicitly ("a line on every diff that says nothing is how a report
stops being read" — the test it replaces). The line does not say nothing; it says which
network the next create lands on. It stays on a clean run that creates nothing, too,
because the trap is set for projects that are already built: the day their server gains
a second destination, every one of them that declared no destination stops being able
to create, and nothing will have warned them.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-14 17:25:29 +00:00
|
|
|
// The claim above is about the UNDECLARED case only. A declared destination
|
|
|
|
|
// makes the opposite statement (it was sent, and cannot be verified) and must
|
|
|
|
|
// never make both.
|
|
|
|
|
it("does not call a declared destination the server's default", () => {
|
|
|
|
|
const out = renderDiff(
|
|
|
|
|
computeDiff([want("a")], [got("a", 3)], "structural", {
|
|
|
|
|
declaredDestination: "dest-abc",
|
|
|
|
|
}),
|
|
|
|
|
);
|
|
|
|
|
expect(out).toMatch(/NOT compared/);
|
|
|
|
|
expect(out).not.toMatch(/none declared/);
|
|
|
|
|
});
|
|
|
|
|
|
feat: place a resource on a destination — and a state file that can say which (#21)
A destination is the Docker network a resource is created on. cast never sent
one, so everything landed on the server's default — invisible and harmless while
each server hosts one project, and neither the moment a server hosts two.
The state file had nowhere to say otherwise, either. A destination is scoped
project × environment, and `environments.<env>` is scoped by environment alone:
a `destination:` key there would mean "one network shared by every project in
this environment", which is the isolation it is meant to provide, inverted.
So:
- `environments.<env>.projects.<repo>` — per-project state, keyed by repo, full
`<org>/<repo>` slug first with a bare-`<repo>` fallback, exactly like
`github_apps`. It carries `destination_uuid` and `smoke_target`.
- `smoke_target` moves there. It was state-file-scoped: it named ONE project's
app (`core`) from a key that could not tell two projects apart — or even prod's
app from staging's. The old key is still read (with a warning), so an unmigrated
state file keeps smoking, and `cast smoke` now takes an optional `<org>/<repo>`.
- `apply` sends `destination_uuid` on create, for applications, databases and
services alike — Coolify runs identical destination logic in all three.
The API turns out to be worse than the issue assumed, in a way that changes what
"diff should compare the destination" can honestly mean. Verified against
coollabsio/coolify v4.1.2 (routes/api.php + the three Api controllers), and
written up in reference/README.md:
- There is NO destinations API. Zero routes. A destination cannot be listed, read
or resolved by name — only a raw UUID from the UI identifies one, exactly as
with `s3_destination`. Hence `destination_uuid:` and not `destination:`.
- The field is WRITE-ONLY. Coolify takes `destination_uuid` on write and returns
`destination_id` (an integer PK) on read, with nothing mapping between them.
- On a server with >1 destination, a create that OMITS it is a hard 400. So cast
could not deploy onto a shared box at all — it did not silently misplace there,
it simply failed. On a single-destination server the uuid is ignored entirely
and never validated, so a wrong one is invisible until a second one exists.
A declared UUID therefore cannot be verified against the resource it was sent
for — by cast or by anything else. Diffing it as a field would compare a UUID to
an int and report drift that never clears, so it is reported rather than compared,
and the limit is stated out loud: every diff that declares a destination says it
did not verify it. Silence would make an unverified setting read as a verified
one, which is the failure shape #12/#14/#17/#18 are all about.
What IS comparable is the live side to itself. `diff` groups live resources by the
`destination_id` Coolify does report, and a project whose resources do not all
share one network is drift — non-clean, both sides named, and never repaired
(apply moves nothing between networks). That catches the thing actually worth
catching, including on a box whose destinations were made by hand.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-13 19:31:02 +00:00
|
|
|
it("names every resource on each side of a split", () => {
|
|
|
|
|
const out = renderDiff(
|
|
|
|
|
computeDiff(
|
|
|
|
|
[want("core"), want("landing")],
|
|
|
|
|
[got("core", 3), got("landing", 7)],
|
|
|
|
|
"structural",
|
|
|
|
|
),
|
|
|
|
|
);
|
|
|
|
|
expect(out).toMatch(/split placement: these resources sit on 2 different/);
|
|
|
|
|
expect(out).toContain("destination 3: application core");
|
|
|
|
|
expect(out).toContain("destination 7: application landing");
|
|
|
|
|
expect(out).toMatch(/apply never moves a live resource between networks/);
|
|
|
|
|
expect(out).toMatch(/split placement$/m);
|
|
|
|
|
});
|
|
|
|
|
});
|
|
|
|
|
|
feat: cast — the Coolify executor, extracted from the infra state repo
Public tool, private state. cast holds no hostnames, no bindings, no
secrets: it joins a product repo's .infra/ manifest with a state directory
you point it at, and makes Coolify match.
Extracted from heavy-duty/infra, which was half tool and half state — the
inconsistency that made it impossible to say whether "infra" named a CLI
or a runbook. rig builds the boxes; cast fills them; infra is what they
are filled with.
Two changes were required to make it genuinely stateless and publishable:
- The implicit cwd contract (environments.yaml / secrets/ / .coolify.env
resolved against the working directory, silently reading the wrong file
from the wrong place) is now an explicit --state <dir> / $CAST_STATE.
- BANNED_IN_PROD — a hardcoded list of one product's ALLOW_* flags, the
only product knowledge in the executor — becomes the generic, operator-
owned environments.<env>.forbidden_var_patterns. The guard now lives in
private state, so a product-side change cannot lower its own guard, and
it is a pattern rather than a list, so it catches unforeseen siblings.
Age identities resolve as $CAST_AGE_KEY_FILE_<ENV> then
~/.config/cast/age-<env>.key — which is the entire attended-vs-unattended
apply mechanism, with no environment names known to the tool.
Instance identity (org names, the GitHub App name, founder domains) is out
of the fixtures and out of register-github-app.sh, which took APP_NAME and
ORG as arguments rather than baking them in.
69 tests green; bin/cast + curl installer mirror rig's shape.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-11 12:25:44 +00:00
|
|
|
describe("renderDiff", () => {
|
|
|
|
|
it("never prints secret values", () => {
|
|
|
|
|
const live = [
|
|
|
|
|
{
|
|
|
|
|
kind: "application" as const,
|
|
|
|
|
name: "core-api",
|
|
|
|
|
uuid: "u1",
|
|
|
|
|
fields: { ...desiredApp.fields },
|
|
|
|
|
env: { PORT: "3000", MAILGUN_KEY: "OLD-SECRET" },
|
|
|
|
|
},
|
|
|
|
|
];
|
|
|
|
|
const out = renderDiff(computeDiff([desiredApp], live, "full"));
|
|
|
|
|
expect(out).toContain("secret MAILGUN_KEY differs");
|
|
|
|
|
expect(out).not.toContain("mk-123");
|
|
|
|
|
expect(out).not.toContain("OLD-SECRET");
|
|
|
|
|
});
|
|
|
|
|
it("structural mode says env was not compared", () => {
|
|
|
|
|
const out = renderDiff(computeDiff([desiredApp], [], "structural"));
|
|
|
|
|
expect(out).toMatch(/env vars not compared \(structural mode/);
|
|
|
|
|
});
|
|
|
|
|
});
|