DDEV shortens local Passbolt setup, but not credential governance

At a glance

What this is: Passbolt’s article explains how DDEV simplifies local development for its API by bundling setup, tooling, and HTTPS into a preconfigured environment.

Why it matters: For IAM and security teams, the main lesson is that developer experience improvements can reduce friction without changing the need for strict secrets, access, and environment governance.

👉 Read Passbolt's article on setting up a local development environment with DDEV

Context

Local development environments often fail because they ask contributors to assemble too many moving parts before they can write code. In this case, the friction came from multi-repository cloning, manual environment files, separate Docker Compose maintenance, and missing defaults for debugging and database access.

For identity and security teams, that matters because developer convenience changes where configuration risk accumulates, not whether it exists. Faster local setup can improve productivity, but it also makes it easier for teams to overlook how secrets, local services, and environment parity should be governed across the software lifecycle.

Key questions

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. The point is to remove unnecessary environment assembly while keeping browser trust, database access, and credential handling inside an approved workflow. Convenience is not the objective on its own. Consistency is what improves both delivery speed and security oversight.

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. When every developer assembles the stack differently, the organisation loses confidence that onboarding, debug access, and local service use follow the same policy. Consistency makes governance visible and makes deviations easier to spot.

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. If the secure workflow is slow or fragile, developers will work around it. A secure environment only helps when it is also the easiest practical option.

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.

Technical breakdown

Why Docker Compose created setup friction for contributors

The earlier workflow required developers to coordinate repositories, copy configuration, edit environment files, and run multiple Compose commands across separate files. That pattern creates operational drift because each developer can end up with a slightly different local stack, especially when database setup and browser trust settings are handled manually. The real issue is not containerisation itself, but the amount of human sequencing required before the environment becomes usable. In practice, high-friction setup slows onboarding and increases the chance that local environments diverge from the intended baseline.

Practical implication: reduce manual environment assembly so contributors start from a consistent local baseline instead of improvised local configurations.

What DDEV changes in local developer identity and access

DDEV packages the local environment, HTTPS, database access, and developer tooling into a repeatable setup. That matters because secure-by-default local services lower the temptation to bypass controls during development, especially when debugging and database inspection are part of the daily workflow. The HTTPS default is especially relevant: it avoids training developers to treat unencrypted local sessions as normal, which can bleed into habits around handling credentials and callbacks. The gain is consistency, not reduced security responsibility.

Practical implication: standardise local developer environments so security controls are built into the default path, not added later by individual teams.

Why performance improvements matter for secure software delivery

Passbolt highlights better performance on macOS and Windows through Mutagen-based file synchronisation. Faster local execution matters because slow environments often cause developers to disable safeguards, skip tests, or avoid running the full stack locally. A responsive environment makes it more likely that people will use the intended tooling, including database browsing and debug support, instead of creating shortcuts. That is a governance point as much as an engineering one: the more painful the approved path, the more likely shadow workarounds become the norm.

Practical implication: treat developer experience as part of security control adoption, because poor performance drives unsafe workarounds.

NHI Mgmt Group analysis

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.

Local HTTPS by default closes a common training gap in secure development. Developers learn what the platform makes easy, and a plaintext local stack teaches the wrong habits around trust, cookies, and callback handling. By normalising HTTPS in development, Passbolt is addressing a real programme weakness: the gap between secure production expectations and insecure local routines. The implication is that environment parity should be treated as part of security design, not as a convenience add-on.

Environment parity debt: manual developer setup creates a hidden cost where each additional local exception increases the chance of configuration drift, unsafe shortcuts, and onboarding delays. This is especially relevant in identity-sensitive software where secrets handling, browser trust, and database access all appear early in the development workflow. If the baseline is too hard to reproduce, teams will keep inventing their own version of it. Practitioners should see reproducibility as a control objective.

Tooling defaults shape whether developers use the secure path or work around it. Bundling Xdebug, Mailpit, and Adminer into a working local stack removes some of the incentives for ad hoc debugging and one-off database access patterns. That matters because friction is often what drives people to improvise with credentials, files, and local services. The broader lesson for identity programmes is that secure workflows have to be usable if they are going to be followed consistently.

This kind of local environment packaging supports stronger lifecycle discipline. When setup is consistent, onboarding and handoff become easier to govern because the local operating model is less dependent on individual memory. That improves the quality of access provisioning, developer offboarding, and shared maintenance across teams. Practitioners should treat the developer workstation and local stack as part of the control surface, not outside it.

From our research:

• 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.
• For lifecycle and secrets governance, see Top 10 NHI Issues for the control patterns that keep local convenience from becoming persistent exposure.

What this signals

Environment parity is becoming a security control dependency. As development stacks move toward preconfigured local tooling, the practical question is no longer whether teams can set up faster, but whether they can do so without weakening the guardrails that protect secrets, browser trust, and shared infrastructure. That is where identity and secrets governance has to intersect with developer tooling policy.

With The State of Secrets in AppSec showing that the average time to remediate a leaked secret is 27 days, friction in local setup becomes more than a developer complaint. It lengthens the window in which poor habits and ad hoc workarounds can persist.

The next step for practitioners is to align local development standards with broader identity lifecycle controls, so onboarding, debugging access, and environment reset processes are all governed as part of the same operating model. That is where consistency starts to pay off as a risk-reduction measure.

For practitioners

• Standardise local development baselines Define one supported local environment path for each engineering stack and remove manual environment assembly where possible. The goal is to make the approved path the easiest path for new contributors and experienced developers alike.
• 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. Treat local trust settings as part of environment policy, not as personal preference.
• 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.
• Measure setup friction as a delivery risk Track how long it takes a new contributor to reach a working environment and use that data to justify removing manual steps, duplicate repositories, and ad hoc configuration tasks.

Key takeaways

• Passbolt’s DDEV approach reduces local setup friction, but it does not remove the need for disciplined secrets and access governance.
• Secure defaults in development matter because they shape the habits that engineers carry into production-facing workflows.
• Standardised local environments improve both onboarding speed and control consistency, which makes them a security issue as well as a developer-experience issue.

Key terms

• Environment Parity: Environment parity is the degree to which development, test, and production workflows behave in a consistent way. In practice, it reduces surprises caused by local-only shortcuts, especially around authentication, secrets handling, and service dependencies. The closer the parity, the less likely teams are to normalise unsafe behaviour in one environment.
• Developer Experience Security: Developer experience security is the idea that security controls must be usable if they are to be followed consistently. When setup is slow or brittle, people invent workarounds that weaken governance. Good security design therefore includes the friction of the approved workflow, not only the strength of the underlying control.
• Local Trust Surface: The local trust surface is the set of browser, service, database, and credential interactions exposed during development. It matters because developers learn habits from the systems they use every day. If that surface is unsecured or inconsistent, the organisation trains people into unsafe patterns before code ever ships.

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.

👉 Passbolt's full post shows the local setup flow, built-in tools, and platform performance details.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.