[Bug] service.environment silently overrides project env on every deploy path (and stores secrets in plaintext)

[greerso]

Self-hosted Openship 0.7.2. Two related findings about how service-level environment is stored and applied. The first cost us a botched credential rotation that reported success; the second is a hardening point.

1. service.environment silently overrides the project env store, on every deploy path

A key present in the environment jsonb on a service row is applied at container creation and wins over the project-level env store. openship project env set on such a key:

• stores the new value correctly,
• reports success,
• is carried into the deployment snapshot,

…and the container still comes up with the old service-level value. No warning anywhere.

Keys absent from service.environment follow the project store normally, for both upserts and deletions — which is exactly what makes this hard to diagnose. Half your changes land and half do not, with no signal distinguishing them.

Every deploy path we tried is affected: deploy --refresh, deployment redeploy, and a full git rebuild producing a brand-new image. All three reported success and changed nothing.

Why it is worse than a normal precedence rule

Precedence between layers is fine and expected. The problem is that the losing layer is the one the CLI writes to and reports on, so the tool tells you the change landed. We hit this rotating an OAuth signing key: the CLI said the key was updated, the deploy went ready, and the application kept signing with the old key. The only way to find out was docker exec <container> printenv <KEY>.

Reproduce

# 1. Pin a key at the service layer
openship api "/projects/<projId>/services/<svcId>" -X PATCH -d '{"environment":{"FOO":"from-service"}}'

# 2. Change it at the project layer — reports success
openship project env set <projId> --set FOO=from-project

# 3. Deploy by any path, then look at what the container actually got
docker exec <container> printenv FOO      # -> from-service

Suggested fixes, roughly in order of value

1. Warn on the write. When project env set targets a key that is pinned in some service.environment in that project, say so on stdout and name the service. This alone would have saved the incident.
2. Surface it in the deployment output, listing keys whose effective value came from the service layer rather than the project store.
3. Expose the effective environment — an openship project env get --effective (or --resolved) that shows, per key, the value that will actually reach the container and which layer it came from.
4. Document the precedence in the env docs. It is currently discoverable only by querying the database.

The supported workaround, once you know, is to write the service layer directly (merge semantics; omit a key to keep it, null to remove) and then update the project layer so the two agree:

openship api "/projects/<projId>/services/<svcId>" -X PATCH -d '{"environment":{"KEY":"value"}}'

2. service.environment and service.buildArgs store secrets in plaintext

The same jsonb columns hold values in the clear, while the same value in the project env store is encrypted at rest. So a secret that is encrypted before it gets pinned is unencrypted after. Two specific observations:

• Anyone with read access to the Openship database reads every pinned secret directly, with no key material required.
• PATCH /projects/<projId>/services/<svcId> echoes buildArgs back in the response body in plaintext, so a routine environment edit prints unrelated build-time secrets to the operator's terminal (and into any log or transcript capturing it).

Encrypting these columns the way env_var is already encrypted, and masking them in API responses the way environment values already are, would close both. The response masking is the cheaper half and worth doing on its own.

Happy to test a fix against a self-hosted instance.

[Hydralerne]

Fixed on feat/bugfix-integration-2026-09-15 and awaiting merge to main.

Project-env writes and deployments warn about service overrides; service environment, build arguments and their saved copies are encrypted at rest. Contributor PR #864 also protects build-argument API responses and masked edits.

Integration commit: d43b3f5001eb64ad907efd712d64a399d98fd6d6, 8c20a9b3, 2763b0cdff1e34316f4d46465e3ebccd8ebf5484.

Validation:

• The full combined branch passed 13,325 tests across 1,003 files and all 10 workspace test tasks, including native/HTTP SDK masking, edits, drift and environment warnings.
• Seven new real PGlite repository cases passed: raw storage protection, legacy conversion across multiple pages, cloning, deployment updates, rollback snapshots, wrong-key/tamper rejection, and empty/prefix-like values.
• Two real PostgreSQL lock races preserved concurrent service/deployment edits. A whole-instance HTTP transfer between separate API processes with different keys preserved inline environment, build arguments and mounted-file content, with masked read responses.
• Three real Docker Compose rollback cases and the real project-store → Docker-build → running-container case passed. The rollback restored the original secret while its database snapshot remained encrypted.
• All 22 build/typecheck tasks, explicit E2E TypeScript checks, documentation validation, and external npm-tarball ESM/CommonJS/native/CLI checks passed.
• Combined-branch CI passed at 2763b0c: https://github.com/oblien/openship/actions/runs/35028598928.

[Hydralerne]

The logic review of #891 removed two remaining copies of environment merging in 9c61d7d9. Backup/restore credentials and rollback previews now use the deployment Compose resolver, including raw expressions and the distinction between legacy blanks and authored empty literals. Missing required backup variables stop preparation with names-only errors. Project reads also match project-write scope in 69e47292.

The regressions reproduced before the fixes; affected environment, backup/restore and preview coverage passed. Fixed in the integration branch; waiting for #891 to merge into main.