v1.11.0 — 1Password secrets on every start, via ddev-1pass

Installing or upgrading ddev-rdg now also installs ddev-1pass. With it, every ddev start resolves the repo's op:// references into env files DDEV loads into the containers, the way dkr up did through op run.

• Nothing to do for a dkr-era repo: the op:// lines in its .env are picked up as they are. Once dkr goes away, move them to a committed .ddev/secrets.env.
• It never blocks the start. If op is missing, signed out or offline, the start warns and carries on with the last good secrets. ddev 1pass-secrets is the strict refresh.
• Needs the 1Password CLI (brew install 1password-cli) with the app's CLI integration turned on, but only in repos that have op:// references.

Upgrading

DDEV 1.25.4 or newer is now required (was 1.24.8). It's the first release that loads the labeled env files the secrets are written to. brew upgrade ddev.

ddev add-on get Rapid-Development-Group/ddev-rdg
git add .ddev && git commit
ddev restart

DDEV skips a dependency that's already installed, so later ddev-1pass releases need their own ddev add-on get Rapid-Development-Group/ddev-1pass.

v1.10.0 — pull from production by default, whatever it is called

With no environment given and none pinned, ddev upsun-db-pull, ddev upsun-files-pull and ddev pull platform|upsun now pull from the project's production environment. Upsun reports it via project:info default_branch.

Newer sites deploy production from main, not master (OP-946), and across the fleet production branches also include rangefinder and trendlabs. So nothing is guessed; the project is asked.

This replaces DDEV's stock fallback, the local git branch. From a feature branch or a worktree, that targeted an environment that usually doesn't exist, and resumed it when it did and was Inactive.

Precedence: explicit argument → PLATFORM_ENVIRONMENT pinned in .ddev/config.yaml → production.

Upgrading: two steps, both needed

1. The provider recipes are not replaced automatically. They omit #ddev-generated on purpose, so ddev add-on get skips them on an existing repo. Delete them first:

rm .ddev/providers/platform.yaml .ddev/providers/upsun.yaml
ddev add-on get Rapid-Development-Group/ddev-rdg

2. Consider dropping your PLATFORM_ENVIRONMENT pin. If .ddev/config.yaml pins PLATFORM_ENVIRONMENT=master and production is master, the pin is now redundant, and it's the thing that breaks the day the project moves to main. Keep a pin only if the repo should pull from something other than production by default.

229 tests, up from 227.

Full changelog: v1.9.0...v1.10.0

v1.9.0 — a theme's 'dev' script, and Vite behind a wrapper

The theme daemon was keyed on a start script in package.json. A repo that had renamed it to dev got no daemon at all — ddev rdg-sync said "no 'start' script, not configuring the theme daemon" and the site came up with assets that never rebuild.

ddev rdg-sync now takes the dev script if there is one and start otherwise, and writes the name it chose into the generated command::

command: "bash /mnt/ddev_config/rdg/theme-watch.sh dev"

dev wins when a repo declares both, because such a repo is mid-migration onto the newer toolchain.

Vite detection no longer requires Vite to be a direct dependency. A script that names vite counts too. Themes that get it through a wrapper (rdg-vite is ours) list no vite of their own, and were handed 35729 while their dev server listened on 5173 — the port exposed, nothing answering on it.

Upgrading

Run ddev rdg-sync after taking this release, then commit. Nothing changes until you do: DDEV never re-derives on an add-on upgrade, and theme-watch.sh defaults to start so an older generated config keeps working untouched.

One derived value may move when you re-sync: a theme whose script runs Vite without depending on it directly changes 35729 → 5173. Read the diff before committing it.

Vite themes: allow the DDEV host

Vite refuses a host it does not recognise, with a 403 that reads as a routing fault:

Blocked request. This host ("rdg2020-vite.ddev.site") is not allowed.

Our shared config still pins the dkr-era allowedHosts: ['vite', 'localhost']. Under DDEV the host is <project>.ddev.site — and since v1.8.1 that follows the directory, so it varies per checkout. Allow the suffix:

server: { allowedHosts: ['.ddev.site'] }

227 tests, up from 220.

Full changelog: v1.8.1...v1.9.0

v1.8.1 — several checkouts of one repo at once

Omit name: from .ddev/config.yaml and DDEV names each project after its enclosing directory — so a worktree per branch, or two clones side by side, run at the same time instead of fighting over one name, one set of containers and one database volume.

git worktree add ../rdg2020-vite vite
cd ../rdg2020-vite && ddev start     # https://rdg2020-vite.ddev.site

Ports were never the problem: everything goes through the one shared ddev-router, routed by Host, the derived theme dev-server on 35728/35729 included. The project name was.

Taking this release does not change any repo on its own. Each repo opts in by deleting its own name: line — and a repo whose directory basename differs from its current project name will be renamed on the next start and lose its containers and database volume, so check that first.

Fixes

• rdg/mailpit-hostname.sh no longer bails when config.yaml declares no name:. Bailing handed mailpit.<project>.ddev.site back to the port-based URL — the exact cross-project collision the file exists to prevent, since 8025/8026 are global.
• A project name carrying capitals is no longer mangled into a broken router. DDEV keeps the case in the container name and lowercases it in the hostname; the two now track separately.

Docs

README.md — Running several checkouts of one repo at once. docs/dkr-to-ddev.md — Two checkouts of the same site, and name: dropped from the three config.yaml templates. Both cover the two things a new checkout does not inherit: the database, and the gitignored Upsun link file that ddev upsun-db-pull needs.

220 tests, up from 217.

Full changelog: v1.8.0...v1.8.1

v1.8.0 — Upsun Flex

Adds Upsun Flex as a third shape, and gives Mailpit's UI a hostname on every repo.

Upgrading a repo that is already on Upsun Fixed needs nothing but the upgrade — no ddev rdg-sync, no new commit. Verified against crcna-d8 and rdg2020-copy: both derive byte-identically to their committed config.platformsh.yaml, and the new pre-start guard passes against those unchanged files.

ddev add-on get Rapid-Development-Group/ddev-rdg
git add .ddev && git commit
ddev restart

Upsun Flex

upsun convert replaces .platform.app.yaml + .platform/services.yaml with one .upsun/config.yaml. Until now that landed a repo in native mode — nothing derived — and ddev upsun-db-pull refused outright.

	fixed	flex
source of truth	.platform.app.yaml + .platform/services.yaml	.upsun/config.yaml
generated	config.platformsh.yaml	config.upsun.yaml
pull provider	platform	upsun
choose among several apps	RDG_APP_ROOT	RDG_APP

It is one parser with two yq prefixes, not a second reader — on Fixed the prefix is . and the output is byte-identical, which the four unchanged goldens assert.

No new API token. The upsun and platform CLIs are the same binary under two names and an Upsun account's token authenticates either, so the Flex recipe falls back to PLATFORMSH_CLI_TOKEN. If a Fixed repo has ever worked on your machine, a Flex one needs nothing.

providers/upsun.yaml is a vetted copy of DDEV's stock recipe with the two changes providers/platform.yaml already carried: one mount downloaded into $DDEV_FILES_DIR rather than every mount into /var/www/html, and both push commands deleted.

Leftover Fixed artifacts never win

upsun convert rewrites the tracked files and nothing cleans up what was not tracked, so a converted repo keeps a .platform/local/project.yaml naming the pre-conversion project, and any checkout of a pre-conversion branch brings .platform.app.yaml back.

• .upsun/config.yaml is checked before every Fixed signal, RDG_APP_ROOT included.
• The shape comes from the tracked config, never a local/project.yaml — those are gitignored, so a fresh clone of a Flex repo had none and reported as "not on Upsun".
• A leftover .platform/services.yaml is neither read nor hashed.
• ddev rdg-sync deletes the other shape's generated file, and the guard refuses while both exist. DDEV merges every .ddev/config.*.yaml, so two means a stale php_version and a duplicate container_port — which DDEV rejects at parse time, taking down the ddev rdg-sync that would fix it.

Mailpit on a hostname

https://mailpit.<project>.ddev.site, generated on install, both modes, nothing to configure.

DDEV serves Mailpit on mailpit_http_port / mailpit_https_port against the bare project hostname, and one ddev-router serves every project — so the default 8025/8026 belongs to whichever started first, and with several projects up ddev mailpit can open another project's inbox without saying so. SMTP is untouched.

Fixed: the app root is no longer guessed

nginx-locations.sh derived the app root as dirname "$docroot", which assumes the docroot is exactly one segment below the app root. styledots is a repo where it is not — app config at the repo root with root: 'drupal/web' — and both halves broke at once: every path came out /var/www/html/drupal/drupal/web/…, and two locations inside the docroot were emitted as if outside it. rdg-sync now passes the app root explicitly.

Also

• A web.locations entry with scripts: true is a PHP entry point, so it is skipped and named on stderr instead of getting a static try_files block that would 404 with confidence.
• The unknown-flag message on ddev upsun-*-pull names the provider the repo actually uses.
• Part 2 of docs/dkr-to-ddev.md documents the stray sites/default/settings.php the first ddev start --skip-hooks scaffolds.

217 tests, up from 148. New fixtures: flex-subdir, flex-stale-fixed (a Flex repo whose leftover Fixed files declare different values at every key, so reading the wrong one fails the golden diff), and nested-docroot.

v1.7.0 — derive the Redis image

Derive the Redis image from .platform/services.yaml

ddev rdg-sync now also writes .ddev/.env.redis, pinning REDIS_DOCKER_IMAGE to the
version the hosted service declares — when the app relates a Redis service and the
ddev-redis add-on is installed.

services.yaml was already an input to this command (read for the database, hashed into
the staleness guard), so the version was sitting there unused.

Why pin. The ddev-redis default is a floating redis:7, and an unpinned major
floats: redis:8 resolves to 8.10 today while the hosted service runs 8.0.6. Two Redis
minors apart is not a difference worth meeting in production.

Notes

• A valkey: service type derives to the Valkey image.
• Relationship-driven: a Redis service the app doesn't relate to is ignored.
• Written only when ddev-redis is installed; removed again only when the file carries
  the generated marker — ddev redis-backend writes the same path without one.
• Changing the version needs the cache volume dropped, at least downwards
  (Can't handle RDB format version N). It's a cache:
  ddev stop && docker volume rm ddev-<project>_redis && ddev start.

Upgrading from v1.5.1 also brings v1.6.0's .ddev/rdg-native opt-out.

148 tests pass.

v1.6.0

Adds .ddev/rdg-native, an explicit opt-out from derived mode.

Mode detection keyed purely off the presence of .platform.app.yaml, which cannot tell config we deploy from apart from config somebody left behind. Repos carrying one from an abandoned Platform.sh evaluation — no .platform/local/project.yaml, and an AWS devops/buildspec.yml instead — landed in derived mode, where the pre-start guard aborts every start until someone runs ddev rdg-sync, which then derives PHP and database versions from a file nobody deploys from.

touch .ddev/rdg-native      # and commit it

The marker beats every other signal, RDG_APP_ROOT included: it is committed and describes the repo, where the variable is a per-shell override.

A file rather than a config key because the guard runs on the host while the project may be stopped, so it can read neither web_environment nor yq.

v1.5.1

Upgrade from v1.5.0 immediately if you have run ddev rdg-sync since installing it.

ddev exec starts the project — and rebuilds the web image when something changed — if it is not already up, and DDEV's own progress output goes to stdout. rdg-sync captured that as part of the derived config and wrote it, so config.platformsh.yaml began with an ANSI escape and DDEV refused to parse the project at all:

control characters are not allowed (value: 27)

That breaks every subsequent ddev command, including the ddev rdg-sync that would repair it. Recovery is git checkout -- .ddev/config.platformsh.yaml (or delete it and re-run after ddev start).

The bug was latent since the command was written; v1.5.0 triggered it by shipping a file that forces an image rebuild.

Fixed with a discarded warm-up ddev exec before gathering, plus a check that the captured output starts the way derive.sh starts — refusing rather than writing something unparseable.

v1.5.0

The theme build toolchain Dockerfile is now shipped with the add-on rather than generated by ddev rdg-sync.

It was previously maintained three ways for identical content: generated on Upsun repos, and hand-written in each native repo — which has no Upsun config to derive from, so it could never receive the file from the add-on at all.

Upgrading

ddev add-on get Rapid-Development-Group/ddev-rdg
ddev rdg-sync      # Upsun repos only; stops emitting the old Dockerfile
ddev restart
git add .ddev && git commit

post_install_actions deletes the old generated web-build/Dockerfile.rdg-theme, which carries no #ddev-generated marker and would otherwise be left behind, installing the toolchain twice. Native repos should also delete their own hand-written copy.

Safe and incremental: nothing here touches a list key, so it cannot cause the duplicate container_port that makes DDEV refuse to load a project. A repo that briefly has both files just runs apt twice.

The # needs-theme-toolchain: header is gone from derive.sh — the only change to the golden files.

v1.4.0 — DDEV-native mode

Repos that are not on Upsun can now use this add-on. Previously they could not start at all: the pre-start guard failed whenever config.platformsh.yaml was absent, fail_on_hook_fail made that fatal, and the recovery it printed died with no .platform.app.yaml.

Two modes, auto-detected, differing in which file is the source of truth:

	source of truth	ddev rdg-sync
derived — Upsun Fixed	.platform.app.yaml	regenerates config.platformsh.yaml; guard enforces freshness
native — everything else	.ddev/config.yaml, hand-written	nothing to derive, and says so

In native mode the guard stands aside, ddev rdg-sync is a no-op that explains which file to edit, and both upsun-*-pull commands refuse and point at ddev import-db. What a native repo gains is rdg/theme-watch.sh and corepack_enable; it declares the theme daemon itself.

The guard only goes inert when there is no app config and nothing generated — if config.platformsh.yaml exists the repo was derived once, so a missing app config is breakage, not a native project, and still fails.

Upgrading is a no-op for existing Upsun projects. Nothing about derived mode changed. Run ddev add-on get Rapid-Development-Group/ddev-rdg as usual — it must be the full add-on get, not a cherry-picked file, since the three commands now source the new rdg/mode.sh.

New: docs/dkr-to-ddev.md Part 3 — migrating a non-Upsun repo off dkr, with the compose-service → DDEV mapping.