A new Git worktree shouldn’t mean another copy of your secrets

Titan Ron — Tue, 27 Oct 2026 20:32:51 +0000

Git worktrees let you keep several branches checked out at once, each in its own directory. Getting your application running in each directory can still involve some manual work.

You create a worktree, install dependencies, and start the app. It fails because the ignored .env file stayed behind in the other checkout.

You can copy the file, create a symlink, or run a script to download the values. Each approach can work, but it adds something to maintain. Copying plaintext secrets also creates more files to keep current when those values change.

I’m building resenv to simplify this part of the workflow: keep references in project configuration and resolve their values when the application starts.

For Node and Nx projects using Doppler, a reference looks like this:

API_TOKEN=doppler://my-project/dev/API_TOKEN

It identifies the project, configuration, and secret to retrieve. The reference itself grants no access. The authenticated developer still needs permission to read that secret.

At startup, resenv fetches the value and replaces the reference in the application’s environment before application imports execute. Your code continues to read process.env.API_TOKEN.

Make the references available in every worktree

Putting references in an ignored .env file removes plaintext values from that file, but the file would still be missing from a new worktree.

To remove that setup step, the reference configuration needs to travel with the project.

Here’s an example using an Nx target. It assumes the application’s entry point is app.mjs inside its project directory.

Install resenv:

npm install --save-exact @ciqol/resenv

Configure authentication using the Doppler setup guide. Supported methods include an explicit token, resenv’s OS credential storage, and existing Doppler CLI credentials. The guide covers platform support and current login limitations.

Then configure the application target:

{
  "name": "api",
  "targets": {
    "serve": {
      "executor": "nx:run-commands",
      "cache": false,
      "continuous": true,
      "options": {
        "cwd": "{projectRoot}",
        "command": "node --import @ciqol/resenv/resolve app.mjs",
        "env": {
          "API_TOKEN": "doppler://my-project/dev/API_TOKEN"
        }
      }
    }
  }
}

This target contains a reference rather than a credential. Project and secret names can still reveal configuration details, so review whether those names are appropriate to include in your repository.

Run the target:

npx --no-install nx serve api

Nx supplies the environment to the application process. The resenv preload resolves the reference before the application starts.

With this configuration available alongside the code, another worktree receives the same reference and startup command. You still install dependencies and complete the application’s usual setup, but you don’t need another plaintext copy of API_TOKEN.

Keep your existing environment loading

resenv resolves values already present in the environment. Your existing loader remains responsible for selecting and loading configuration files.

In the example above, the reference is explicitly supplied through the target’s env option, which Nx gives precedence over dotenv files. If you prefer file-based overrides, references can live in the files your loader selects instead. Those files still need to be provisioned in each worktree.

The preload belongs on the application process, after its environment has been loaded. Preloading the outer Nx process would run too early.

Each reference explicitly selects its Doppler project and configuration. Worktrees can use the same references or different ones where needed; resenv doesn’t choose a configuration from the branch name.

Resolution happens once at startup. Restart the application to fetch updated values. If a required lookup fails, startup stops before resenv applies replacements.

Where this fits among the alternatives

Doppler CLI already supports injecting secrets for a selected project and configuration. 1Password CLI supports resolving secret references at runtime too.

resenv focuses on resolving individual Doppler references within the environment your Node application already receives. That includes Nx’s existing loading flow and references pointing to different Doppler projects or configurations.

The benefit I’m trying to validate is less setup when moving between worktrees, while keeping the application’s environment-loading conventions.

A specific security benefit

resenv doesn’t write fetched values back into dotenv files or cache those values on disk. This reduces the need to maintain plaintext secret files in working directories.

Your application still receives the resolved secrets. resenv doesn’t isolate worktrees or programs running with access to the same credentials. Doppler permissions remain the authorization boundary.

resenv is available as an experimental beta. It currently supports Doppler as its only built-in cloud provider, requires Node.js 20 or later, and has no runtime npm dependencies.

I’m looking for feedback from developers working across multiple Git worktrees:

How do you make secrets available in a fresh worktree today, and which part of that setup would you most like to remove?

Source and setup instructions · Share feedback

What Karate Taught Me About Engineering Leadership

Titan Ron — Wed, 24 Jun 2026 22:27:57 +0000

I recently published a personal reflection about something I did not expect to connect so strongly:

Karate and engineering leadership.

As of writing the article, I have practiced karate for more than 20 years. For a long time, karate was karate, and work was work.

But over time, especially around architecture, migrations, incidents, and team leadership, I started seeing the overlap.

A few ideas from the article:

Pressure reveals training

In engineering, incidents and migrations do not usually create the real gaps.

They reveal them.

Ownership gaps
Missing context
Hidden assumptions
Unclear flows
Places where people are afraid to say “I don’t know”

That reminded me a lot of training.

Under pressure, you do not always get to choose how you react. You fall back to what was actually practiced.

Simplicity is not shallow

In karate, a basic movement can look simple from the outside.

But after years of practice, you realize that simple does not mean easy.

I think good architecture is similar.

The best architecture is not always the most advanced one. Sometimes it is the one people can actually understand, operate, and improve.

Always be a student

One sentence my sensei often says stayed with me:

תמיד תהיה תלמיד

Always be a student.

For me, this became a leadership lesson.

Being responsible for something does not mean pretending to know everything.

It means caring enough to keep learning.

And it also means creating enough trust so others can say:

I do not know.

I am missing context.

I need help connecting the dots.

Because if I do not know what is missing, I cannot help.

The full article

I wrote the full reflection here:

medium.com

Would love to hear how other engineers think about this.

What is something outside of software that shaped the way you write code, lead teams, or think about systems?

DEV Community: Titan Ron