Notifications
Clear all
Topic starter
08/07/2026 7:08 pm
TL;DR: A DDEV-based setup can replace a multi-repository Docker Compose workflow with a preconfigured local environment that includes HTTPS, Xdebug, Mailpit, Adminer, and faster macOS and Windows performance, according to Passbolt. The operational gain is real, but identity and secrets handling still need deliberate separation between development convenience and production control.
NHIMG editorial — based on content published by Passbolt: Set Up Your Local Passbolt Development Environment in Minutes with DDEV
Questions worth separating out
Q: How should teams reduce local development friction without weakening security controls?
A: Use a preconfigured local baseline that includes secure defaults, repeatable tooling, and minimal manual setup.
Q: Why does developer environment consistency matter for identity and access governance?
A: Because inconsistent local environments create exceptions that are hard to audit and easy to normalise.
Q: What do security teams get wrong about secure development environments?
A: They often treat local setup as a purely engineering concern, even though it shapes how people learn to handle trust, credentials, and access paths.
Practitioner guidance
- Standardise local development baselines Define one supported local environment path for each engineering stack and remove manual environment assembly where possible.
- Keep HTTPS on in local workflows Require secure local defaults for services that interact with browser sessions, callbacks, or credentials so developers do not normalise plaintext testing.
- Review developer tooling as part of access governance Map which local tools expose data, databases, or mail flows during development and make sure those tools are included in onboarding, offboarding, and least-privilege reviews.
What's in the full article
Passbolt's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step local setup commands for getting the Passbolt API running in DDEV.
- The full list of built-in developer tools, including HTTPS, Xdebug, Mailpit, and Adminer.
- The exact differences between the older Docker Compose approach and the new DDEV workflow.
- Mac and Windows performance notes that explain why the new setup feels faster in practice.
👉 Read Passbolt's article on setting up a local development environment with DDEV →
DDEV for local Passbolt development: what changes for teams?
Explore further
08/07/2026 7:33 pm
Developer experience is a governance control, not just a productivity feature. When local setup requires manual coordination across repositories, environment files, and tooling, teams create predictable drift between intended and actual developer behaviour. That drift does not create an identity breach by itself, but it does weaken the reliability of the secure path that IAM, secrets, and access controls depend on. For practitioners, the lesson is that standardised local environments reduce operational exceptions before they become security exceptions.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant behaviour gap.
A question worth separating out:
Q: Who should own developer environment standards in an organisation?
A: Engineering should own implementation, but security and IAM teams should help define the baseline because local workflows influence access, trust, and secret handling. Shared ownership prevents the environment from becoming a series of one-off personal setups. Governance belongs where the risk lands, not only where the code runs.
👉 Read our full editorial: DDEV shortens local Passbolt setup, but not credential governance
