DROP 1.3.0

[1.3.0] - 2026-08-14

A security fix in how depends_on reaches an app's environment, and support
for external databases through the encrypted secret store.

Prioritise this upgrade if you deploy a drop.yaml you did not write — a
third-party repository via deploy_from_git, or an agent-authored manifest. On
those paths the manifest author and the app owner are different people, and a
depends_on entry could overwrite any variable in the app's start environment,
the owner's own secrets included. A box that only ever deploys its operator's
own code was never exposed to the sharp half of this.

Security

• depends_on in drop.yaml could overwrite anything in an app's start
  environment. Resolved dependency URLs were applied last, so a depends_on
  entry could name any variable and silently win — a platform value such as
  DROP_API_URL (redirecting where the app sends the scoped control-plane key
  DROP mints for it), a provisioned DATABASE_URL or REDIS_URL, or any
  secret the app's owner had set. The last of those is the sharpest: an
  overwritten secret also satisfied the required-secret preflight, because that
  check reads the merged environment — so instead of parking in needs-config,
  the app started with a session or signing key the manifest author chose.
  This matters most when deploying a third-party repository, where the manifest
  author and the app owner are not the same person.

  A depends_on entry may now only fill a gap in the environment, never
  overwrite an entry already in it. The collision is logged and that one
  injection is skipped, so an unrelated attempt cannot fail an otherwise valid
  deploy. The check compares against the environment actually assembled rather
  than a list of protected names, so a variable added in future is covered
  without anything to keep in sync. depends_on[].env values that are not
  usable environment variable names are skipped the same way — skipped rather
  than rejected during parsing, because a failed drop.yaml validation
  discards the entire manifest, which would both break already-deployed entries
  and disable the required-secret preflight that depends on the discarded
  secrets: block.

Added

• External databases can now be configured through the encrypted secret
  store. Storing a DATABASE_URL secret (Supabase, Neon, RDS, an external
  MySQL) was refused outright, which left a plaintext env: entry in the
  tenant's own drop.yaml as the only way to point an app at one. It is now
  refused only when the app already has a DROP-managed database, whose
  injected URL takes precedence over any secret and would override it anyway.
  PGHOST, PGPORT, PGUSER, PGPASSWORD and PGDATABASE stay reserved,
  alongside PORT, NODE_ENV and DROP_DATA_DIR.

Fixed

• database: true silently discarded an app's env:, secrets: and
  services:. The validator required database to be a string, so
  database: true failed validation and the whole manifest was dropped —
  while a second, unvalidated reader went on provisioning the database, making
  the loss easy to miss. database now accepts a boolean at the top level and
  per service, matching what the platform actually acts on.
• A monorepo service's database declaration survives materialisation. The
  generated child config was written with a truthy test, so database: false
  was dropped entirely rather than passed down. Note that database: false
  still does not decline a database — it falls through to auto-detection, as it
  always has. Making it a real opt-out needs a deprovision story first, since an
  app that already has a DROP-managed database cannot hand it back.