[mjafartp]

Summary

The Resources form and the API accepted any string for Memory Limit, Memory Reservation, CPU Limit and CPU Reservation. calculateResources reads them with Number.parseInt, so 1792MB became 1792 bytes and 1.5 CPU became 1 nanoCPU. Swarm rejected the service spec at deploy time with Must be at least 4MiB / Must be at least 0.001, and values the manager accepts but the engine refuses (memory below 6 MiB) fail on the node instead.

The two reservation tooltips were also wrong: reservations are used for scheduling placement only and never limit the container.

Changes

• db/schema/shared.ts: resourceBytesSchema and resourceNanoCpusSchema. Empty or 0 still means no limit; otherwise the value must be a whole number no lower than Docker's minimum (6 MiB of memory, 0.001 CPU), with a message that names the unit.
• Applied to the four resource fields in the application schema and in the libsql, mariadb, mongo, mysql, postgres and redis schemas, so the update endpoints reject a bad value on save instead of at deploy.
• show-resources.tsx: the same rule in the form schema, so the user sees an inline message before submitting; reservation tooltips corrected.

Notes: the 6 MiB minimum is applied to reservations as well as limits for simplicity (Swarm's own floor for reservations is 4 MiB). Values already stored are not migrated; an invalid one shows the inline error the next time the form is saved. openapi.json is not regenerated here since CI does that on canary.

Tests

• New __test__/server/resource-schema.test.ts (38 tests): both helpers accept null, empty, 0 and valid digit strings and reject 1792MB, 1.5, 2e9, negative and under-minimum values with one message each; every apiUpdate* schema rejects a bad value and accepts null and a valid value; calculateResources behaviour.
• libsql/create-schema, mechanizeDockerContainer, application.command, preview-build-server, provider-status: pass. Full suite: 1532 passed. tsc --noEmit for server and dokploy: pass. Biome: clean.

Confidence Score: 4/5

The PR appears safe to merge, with a non-blocking improvement needed for numbers outside JavaScript’s safe integer range.

Summary

Adds resource checks before saving application and database settings.

• Resource fields reject malformed memory and CPU values before deployment.
• Reservation hints explain that reservations guide scheduling, not container limits.

Acknowledged choices:

• mjafartp explicitly chose the 6 MiB minimum for memory reservations as well as limits, for simplicity.
• mjafartp explicitly deferred migration of stored values and regeneration of openapi.json; CI regenerates the latter on canary.

_{Reviews (1) · Last reviewed commit: "fix(resources): validate memory and CPU ..." · Reviewed by Greptile}

[greptile-apps]

Large resource numbers lose precision

resourceValueSchema accepts digit strings that JavaScript cannot preserve as integers. For example, 9007199254740993 passes, but calculateResources converts it to 9007199254740992. Sufficiently long strings become Infinity.

Check that nonzero values convert to safe integers, apply the same check in show-resources.tsx, and add boundary tests. This would keep accepted values from changing when the server prepares them for deployment.