DEV Community: Ustun Ozgur

A Practical Guide to Moving from AWS App Runner to ECS Express Mode

Ustun Ozgur — Wed, 08 Apr 2026 10:26:03 +0000

Most teams hear "App Runner is closing to new customers" and think: swap the
runtime resource, point DNS at the new service, done.

In practice, the migration is bigger than that.

AWS now recommends Amazon ECS Express Mode as the migration path. App Runner
closes to new customers on April 30, 2026. Existing services keep running, but
no new features are planned. If you are still on App Runner, the clock is
ticking.

The reason the migration feels deceptively small is that App Runner often sits
in the middle of several things operators rely on: custom domains, TLS
certificates, WAF rules, CI/CD assumptions, health checks, deployment and
rollback habits. Change the runtime and you may discover that half of those were
tightly coupled to it.

This is the playbook I would hand someone starting this migration today.

Start with the Right Mental Model

Do not treat this as a resource rename.

Treat it as a platform migration with at least four moving parts:

runtime
public edge
deployment workflow
operational recovery paths

The runtime is only one layer. Teams lose time when they update the service
first and only later discover that deploys, health checks, certificates, DNS,
or WAF behavior were tightly coupled to App Runner.

What Usually Carries Over Cleanly

The easiest migrations already have these characteristics:

the application already runs from a container image
images are already published to ECR or another registry
environment variables and secrets are already separated
the application exposes a stable health endpoint
the team already has separate app-only and infra-only operational flows

If you already build an image and ship that image, you are in good shape. That
means the migration is mostly about runtime and edge behavior, not packaging.

One note: if your App Runner service currently deploys from source code rather
than a container image, you will need to add a build step that produces an image
and pushes it to a registry like ECR. Plan for that work separately.

What Changes in ECS Express Mode

ECS Express Mode keeps the simple "give AWS an image and let it run" model, but
it does so by creating ECS and load-balancer infrastructure in your account. You
gain visibility into underlying resources, but you also inherit integration
points around them.

This is where many migrations get harder than expected. Your new runtime may be
simple to create, but your operational tooling now has to coexist with
load-balancer, listener, target-group, certificate, and routing behavior.

Observability changes: X-Ray is no longer built-in

App Runner had native X-Ray integration. You toggled a setting in the
observability configuration, and App Runner handled the rest. The ADOT
collector ran behind the scenes without you managing a sidecar or daemon.

ECS does not work that way. To get X-Ray tracing on ECS (including Express
Mode), you need to run the X-Ray daemon as a sidecar container in your task
definition, instrument your application with the ADOT or X-Ray SDK, and
configure the appropriate IAM permissions on your task role. It is not
difficult, but it is not free either. Plan for an extra container in your task
definition, the associated CPU and memory overhead, and the time to verify that
traces are actually flowing.

If your team relied on App Runner's built-in tracing for debugging production
issues, do not leave this until after the migration. Set it up during the
parallel validation phase so you have the same visibility on the new service
before you shift traffic.

Cost changes: the ALB you did not used to pay for

App Runner included load balancing in its pricing. You did not see a separate
ALB line item on your bill.

ECS Express Mode creates an Application Load Balancer in your account. An ALB
costs roughly $16-25/month just to exist, even with zero traffic. For teams
running multiple environments (dev, staging, production), that adds $50-75/month
in load balancer costs before any compute charges.

Express Mode can share a single ALB across up to 25 services with compatible
networking configurations, which helps. But if your services have different
networking shapes or you need isolation, you may end up with multiple ALBs.

For small, low-traffic services where App Runner's pricing was attractive
precisely because of its simplicity, the additional ALB cost is worth
modeling before you migrate. It may not change your decision, but it should not
be a surprise on your first bill.

The Migration Plan I Recommend

1. Inventory the App Runner service before changing anything

Write down the current behavior, not just the current Terraform or console
shape.

Capture:

container image and tag strategy
CPU and memory settings
environment variables
Secrets Manager references
health endpoint and expected response
custom domains
certificate ownership
WAF and allowlist behavior
observability settings (X-Ray enabled or not, and how traces are consumed)
deployment commands people actually use

This becomes your migration acceptance checklist.

2. Preserve the image pipeline

The safest migration keeps the build artifact exactly the same.

If App Runner currently runs image X, the first ECS Express deployment should
also run image X. Do not combine a runtime migration with a packaging change
unless you absolutely have to.

That one decision removes a large class of risk.

3. Bring up ECS Express in parallel

Create the Express service with the same image, the same key environment, and
the same secret references.

Do not move public traffic yet.

Validate the service using its generated endpoint first:

container starts
app answers health checks
database connectivity works
Redis or other private dependencies work
logs and metrics show up where you expect
X-Ray traces are flowing (if you had tracing enabled on App Runner)

This is the point where you learn how Express behaves in your actual account and
network shape.

4. Rebuild the edge deliberately

This is where most hidden complexity lives.

Plan for:

ACM certificate creation and validation
Route 53 record changes
ALB listener and host-routing behavior
WAF attachment and policy scope

One of the easiest mistakes is assuming that "runtime healthy" means "public
URL healthy." That is not always true, especially when WAF sits in front of the
service.

Use different signals for different questions:

service rollout health
target-group health
public edge reachability

They are related, but they are not interchangeable.

5. Shift traffic gradually

Use a blue/green mindset, even if the final architecture is simple.

The broad shape is:

keep App Runner serving production traffic
stand up ECS Express in parallel
shift a small percentage of traffic to ECS Express
observe errors, latency, auth, and edge behavior
complete the cutover
keep App Runner around briefly for rollback confidence

Weighted DNS is a good fit for this because it gives you a straightforward
rollback path.

6. Re-verify operator workflows before deleting App Runner

This step gets skipped surprisingly often.

Before retiring App Runner, explicitly verify:

app-only deploy
infra-only apply
full deploy
secret rotation path
manual recovery path for custom domains
CI/CD workflows

If your team had three deploy paths before the migration, you should assume
people still need three deploy paths after it.

The Most Common Pitfalls

Public health checks can lie

If your public URL is protected by WAF or allowlists, a deploy script that
simply curls the public health endpoint may fail even when the backend is
perfectly healthy.

A better deployment gate is usually:

service rollout complete
target group healthy

Then use the public health endpoint as a separate edge verification signal.

Shared ALBs reduce cost and increase coupling

Express Mode can share Application Load Balancers across services that use the
same networking shape. The cost benefit is real, but so are the tradeoffs: more
host-based routing logic, more shared listener behavior, and more care required
when updating custom-domain rules.

If you have multiple public service surfaces, understand whether they will land
behind one shared ALB or separate ones before you design your routing and WAF
strategy.

Terraform will not always tell you everything during plan

This is especially true with newer resource types and services that create
dependent infrastructure on your behalf.

Be ready for cases where plan succeeds, validate succeeds, and apply reveals an
API-side constraint or provider mismatch. That does not mean Terraform is
failing you. It means you still need a real staging apply as part of the
migration process.

Also worth noting: the Terraform AWS provider has already opened issues to
deprecate App Runner resources in a future major version. If you are managing
App Runner with Terraform, expect provider-level changes in the coming months.

Secret references and secret values are not the same thing

Changing the ECS service definition is one class of update. Changing the value
inside Secrets Manager without changing the reference is a different class of
update.

Make sure your team has a clear answer to both questions:

how does the service pick up a changed environment variable definition?
how does the service pick up a rotated secret value behind the same ARN?

Those are often different mechanisms.

Do not let the migration silently change deploy contracts

If deploy-app meant "ship application code" before the migration, it should
still mean that afterward.

Migrations become much harder to validate when runtime behavior and operator
behavior change at the same time.

When ECS Express Mode Is a Good Fit

ECS Express Mode is a strong choice when:

you want to stay container-first
you want AWS-managed defaults
you want the underlying resources in your account
you do not want to hand-build every ECS and ALB component

It is especially attractive for teams that have outgrown App Runner but still
want a fairly managed experience.

When You May Want Standard ECS Instead

If you need deep control over deployment tuning, target-group behavior, listener
layout, load balancer isolation, or blue/green strategy details, then standard
ECS/Fargate with explicitly managed ALB resources may be a better fit.

That is not a knock against Express Mode. It is a recognition that managed
abstractions are most helpful when their defaults line up with your operational
needs.

It is also worth noting that ECS Express Mode does not currently support
blue/green deployment. If that is a hard requirement for your team, standard
ECS gives you more options.

A Short Acceptance Checklist

Before calling the migration done, verify all of these:

ECS Express is running the same image you expected
direct service endpoints are healthy
custom domains serve the correct service
TLS certificates are valid
WAF behavior still matches policy
X-Ray tracing works (if previously enabled)
app-only deploy works
infra-only apply works
full deploy works
secret rotation works
ALB cost is understood and budgeted
rollback steps are documented and tested

If even one of those is still "probably fine," the migration is not done yet.

Final Advice

The best way to reduce risk is to separate the migration into phases:

create ECS Express
validate it privately
move traffic
verify deploy workflows
remove App Runner

Teams lose the most time when they try to do all five in one move.

If you plan the migration as a runtime swap, you will probably underestimate it.
If you plan it as a platform-and-edge migration, you will make better decisions
earlier.

Terraform HCL for Developers: Why It Feels Familiar and Strange

Ustun Ozgur — Mon, 06 Apr 2026 20:48:07 +0000

If you're coming to Terraform from Python, JavaScript, or Ruby, HCL can feel uncanny: familiar enough to read, strange enough to second-guess.

You see list-like comprehensions, Ruby-ish blocks, and syntax that looks a bit like assignment without really behaving like a programming language. That is not accidental. HCL is a hybrid—a configuration language designed to be readable by humans and useful for describing infrastructure, relationships, and constraints.

The mental shift that helps most is this:

You are not writing a script that runs top to bottom. You are declaring a desired shape of infrastructure, and Terraform turns that declaration into a dependency graph, a plan, and an execution strategy.

Once that clicks, most of HCL's weirdness starts to make sense.

1. It's a graph, not a script

In Python or JavaScript, source order usually matters because execution is fundamentally sequential. In Terraform, block order does not define execution order. References between objects—and, when needed, explicit depends_on edges—do.

That is why you can scatter related resources across multiple .tf files without teaching Terraform what runs first. Terraform builds a dependency graph from the configuration and uses that graph to generate a plan and sequence operations.

That does not mean every fact is always known before apply. In many cases Terraform can resolve values during planning, but some data sources may be deferred until apply if their inputs are not known yet.

So the right mental model is not “top to bottom.” It is “describe the relationships, then let Terraform walk the graph.”

2. HCL is built from arguments and blocks

The most important syntax distinction in Terraform is not really about operators. It is about arguments and blocks.

resource "aws_instance" "web" {
  ami           = "ami-1234567890" # argument
  instance_type = "t3.micro"       # argument

  tags = {                         # argument whose value is an object
    Name = "web"
  }

  ebs_block_device {               # nested block
    device_name = "/dev/sda1"
    volume_size = 50
  }
}

Arguments assign values to names. Blocks are containers for more configuration and usually represent schema-defined structure.

They can look similar when you're new to HCL, but they are not interchangeable. Understanding that explains a lot of Terraform's “why does this parse but that doesn't?” moments.

It also explains why dynamic blocks exist. Expressions can compute argument values directly, but nested blocks are structural, so Terraform needs a dedicated construct to generate them.

3. The expression language is where HCL feels Pythonic

Inside argument values, HCL has a compact expression language: functions, conditionals, indexing, attribute access, and for expressions.

This is the part that often feels most familiar to developers coming from general-purpose languages.

subnet_ids = [for s in aws_subnet.private : s.id]

subnet_map = {
  for s in aws_subnet.private : s.tags["Name"] => s.id
}

for expressions are one of the cleanest parts of the language. Square brackets produce a tuple/list-like result. Curly braces produce an object/map-like result. In object for expressions, => maps a computed key to a computed value.

There is also only one real inline conditional form:

var.enabled ? 1 : 0

That is deliberate. HCL gives you enough expression power to transform data, but it stops well short of becoming a full programming language with arbitrary control flow.

4. Instance identity matters more than iteration

If you want to understand why Terraform sometimes feels fussy, look at for_each.

For resources and modules, for_each accepts a map or a set of strings. Terraform identifies each instance by the map key or set member. That is the real reason toset() shows up so often: it lets you create instance addresses based on stable values instead of numeric positions.

locals {
  environments = toset(["dev", "staging", "prod"])
}

resource "aws_s3_bucket" "env" {
  for_each = local.environments
  bucket   = "my-app-${each.key}"
}

This is safer than list-indexed identity, but it is not magic.

Reordering the original list before converting it to a set does not matter. Changing the key does matter, because Terraform uses that key as the instance identity. If you intentionally rename or move an object address, moved blocks are the right way to preserve that refactor.

5. State is the hidden half of the model

Terraform is declarative, but it is not stateless.

It persists state so it can map configuration objects to real infrastructure, track metadata, and make planning practical at scale. Terraform then compares your configuration with its state and the existing infrastructure to decide what needs to change.

That is why HCL alone is never the whole story. Two identical-looking .tf files can behave differently depending on what Terraform already believes it manages.

This is also why backends, locking, drift, imports, and refactors matter so much operationally: they are all state-management problems wearing different costumes.

6. Where the chimera gets awkward

HCL is excellent at describing structured infrastructure. It is much worse at acting like a general-purpose language.

String manipulation gets unreadable quickly. Branching is intentionally limited. dynamic blocks solve a real problem but can become cryptic fast.

And while Terraform's validation and testing story is better than it used to be—you now have variable validation, preconditions, postconditions, check blocks, and terraform test—it still feels different from application development. Complex module testing can still be heavier and less ergonomic than writing ordinary unit tests in an application language.

That is not a flaw so much as a boundary. HCL works best when you let it describe infrastructure shape, identity, and dependency, and move business logic or heavy data wrangling elsewhere.

Conclusion

HCL feels hybrid because it is.

It borrows just enough from programming languages to be expressive, but it stays rooted in configuration: blocks, arguments, expressions, and graphs.

Once you stop reading it like a script and start reading it like a human-friendly language for declaring structure and dependency, most of its weirdness starts to look intentional.

And that is usually the moment Terraform clicks.

Find Plaintext Secrets Hiding in Your .env Files

Ustun Ozgur — Wed, 25 Mar 2026 10:41:22 +0000

This is a companion to my earlier post, A Small Hardening Trick for .env.local: dotenvx + OS Keychain, where I described a pattern for encrypting local secrets with dotenvx and storing the decryption key in the OS keychain.

That post was about fixing the problem. This one is about finding it first.

The problem with "just gitignore it"

If you have been developing locally for a while, you probably have .env files
scattered across dozens of project directories. Some are recent, some are from
projects you have not touched in months. Some contain harmless config. Some
contain database URLs, API keys, and auth secrets in plaintext.

The trouble is that you do not always know which is which, especially once you
have 10 or 20 repos checked out under ~/code. And if a supply chain attack or
a compromised tool scans your filesystem, it does not care whether you remember
what is in those files.

I wanted a quick way to answer one question: where on my machine are plaintext
secrets sitting in .env files right now?

The script

I wrote a small bash script that walks a directory tree, finds .env files, and
reports lines that look like they contain secrets. It is deliberately simple,
opinionated, and safe to run.

The full script is at the end of this post. Here is what it does.

What it scans:

It looks for files named .env, .env.production, .env.local, and
.env.local.secrets. It skips node_modules, .git, build output, caches,
and other directories you would never want to crawl.

How it matches:

It uses rg (ripgrep) to find lines matching a pattern. The default pattern is
token|api|key, which catches most secret-looking variable names without
generating too much noise. You can override it:

bash find-env-secret-patterns.sh --pattern 'token|secret|api|key|password'

What it skips:

Lines containing encrypted: (already handled by dotenvx), DOTENV_PUBLIC_KEY
(not a secret), USE_KEYCHAIN_FOR_DOTX (a config flag, not a credential), and
the dotenvx public-key header comment are all ignored. For .env.local.secrets
files specifically, it only reports lines that look like env-style assignments
(KEY=value), since the rest of an encrypted file is ciphertext noise.

What it outputs:

Every match is printed as filepath:line_number:KEY=[REDACTED]. The script
redacts everything after the = sign, so you can share the output or paste it
into a ticket without leaking actual values.

Usage

# scan your entire home directory (the default)
bash find-env-secret-patterns.sh

# scan only your code directory
bash find-env-secret-patterns.sh --root ~/code

# use a broader pattern
bash find-env-secret-patterns.sh --pattern 'token|secret|api|key|password|credential'

Example output:

/Users/you/code/project-a/.env.local:3:GOOGLE_CLIENT_SECRET=[REDACTED]
/Users/you/code/project-a/.env.local:5:POSTGRES_URL=[REDACTED]
/Users/you/code/project-b/.env:2:STRIPE_API_KEY=[REDACTED]
/Users/you/code/old-project/.env.production:8:AUTH_TOKEN=[REDACTED]

Each of those lines is a plaintext secret sitting on your disk.

What to do with the results

The output tells you where your exposure is. From there you have a few options
depending on how much effort you want to put in:

For active projects, this is a good prompt to adopt the dotenvx + OS keychain
pattern from the first post: Split secrets into .env.local.secrets, encrypt them, move the key into your keychain, and those files will stop showing up in future scans.

For old projects you are not actively working on, consider whether those .env
files need to exist at all. If you have not touched a project in six months, the
credentials in its .env.local might be stale, but they might also still be
valid. Deleting or encrypting them reduces your surface.

For production env files (.env.production), those should probably not be on
your machine in plaintext at all. If they are showing up in the scan, that is
worth a closer look at how your deployment pipeline distributes config.

Running it periodically

You could add this to a cron job or a weekly reminder. The script exits with
code 0 on success (whether or not it found matches) and code 1 on errors, so
it plays well with automation. If you want to fail a CI check when plaintext
secrets are found, you could adjust the exit code for the FOUND_MATCH case.

Design decisions

A few things I was deliberate about:

Redaction by default. The script never prints secret values. It shows you the
variable name and the file location, which is enough to act on. This means you
can pipe the output into a log or share it with a teammate without worrying.

rg over grep. ripgrep is faster on large directory trees and handles
null-delimited input cleanly. If you do not have rg installed, brew install ripgrep or your package manager equivalent.

Skipping dotenvx artifacts. If you have already encrypted a file with
dotenvx, the script should not flag it. The skip patterns for encrypted: and
DOTENV_PUBLIC_KEY handle this. The .env.local.secrets special casing is there
because an encrypted file still has key-looking variable names in its ciphertext
lines, but those are not plaintext secrets.

find with -print0 and null-delimited reads. Filenames with spaces or
special characters will not break the script. This matters less for .env files
specifically, but it is a good habit.

The full script

The complete script is in this gist:
find-env-secret-patterns.sh

Closing thought

Encrypting secrets is the fix. But knowing where unencrypted secrets are sitting
is the prerequisite. You cannot harden what you have not inventoried.

Run this once across your home directory and see what comes back. Then do the hardening steps in the previous post.

A Small Hardening Trick for .env.local: dotenvx + OS Keychain

Ustun Ozgur — Wed, 25 Mar 2026 08:53:02 +0000

Most teams keep local secrets in .env.local and add that file to .gitignore.
That is the bare minimum, and it does not address a more pressing risk: supply
chain attacks and compromised local tooling that read .env files as soon as
they get repo access.

Once a malicious dependency, postinstall script, editor extension, MCP server,
AI coding tool, or other local helper can inspect your workspace, plain-text
.env.local files become low-effort, high-value targets.

I wanted a low-friction way to reduce that blast radius without forcing the whole
team onto a heavyweight secrets manager for day-to-day local development.

This is the pattern I landed on:

keep non-secret local config in .env.local
move actual secrets into .env.local.secrets
encrypt .env.local.secrets with dotenvx
move the decryption key out of disk and into macOS Keychain
load .env.local first, then only decrypt secrets when an explicit opt-in flag says to

Important distinction: I am not using dotenvx the way it is often
marketed, where encrypted env files are committed to the repo and shared that
way. This setup is local-only. The encrypted file and .env.keys both stay
uncommitted, and I prefer it that way. Committing encrypted env files is useful
when you want team-wide encrypted config distribution, but that was not my goal.
I wanted to reduce plaintext secrets on developer machines and raise the cost of
tools that slurp local env files, while keeping the workflow simple enough that
teammates actually use it.

The setup

Start with a normal .env.local, then split it:

.env.local: safe local config, feature flags, non-secret defaults
.env.local.secrets: secrets only

Example:

# .env.local
BETTER_AUTH_URL=http://localhost:3000
USE_KEYCHAIN_FOR_DOTX=true

# .env.local.secrets
POSTGRES_URL=postgres://...
GOOGLE_CLIENT_SECRET=...
BETTER_AUTH_SECRET=...

Make sure your .gitignore covers all the pieces:

.env.local
.env.local.secrets
.env.keys

Then encrypt the secrets file:

pnpm exec dotenvx encrypt -f .env.local.secrets

That gives you an encrypted .env.local.secrets and a decryption key in
.env.keys.

At this point, you have improved at-rest security a bit, but the key is still on
disk, which is not the end state we want.

Why bother with the extra steps?

There have been enough supply chain and developer tooling incidents lately that I
no longer treat "it is gitignored" as a meaningful security boundary. Once
something malicious lands in your development environment, one of the first
profitable things it can do is read local env files and exfiltrate credentials.

Encrypting local secrets at rest is not a complete defense, but it is a useful
speed bump:

secrets are no longer sitting in plaintext on disk
the decryption key can live in the OS keychain instead of another dotfile
accidental repo-wide file reads become less damaging
you can keep the workflow mostly compatible with existing frameworks

This does not protect secrets after your app starts. At runtime, the process
still has decrypted environment variables in memory. But that is still better
than leaving everything plaintext on disk all the time.

Move the key into macOS Keychain

Copy the DOTENV_PRIVATE_KEY_LOCAL_SECRETS value from .env.keys, then store it
in Keychain:

security add-generic-password -U \
  -a LOCAL_SECRETS_DOTENVX_KEY \
  -s LOCAL_SECRETS_DOTENVX_KEY \
  -w

With security, keeping -w as the last argument makes it prompt you for the
secret instead of putting it in your shell history.

The LOCAL_SECRETS_DOTENVX_KEY label is just an example. Pick any consistent
Keychain item name you want, then use that same name everywhere in your scripts.

Now you can delete .env.keys. Before you do, stash the key somewhere safe
outside the repo. A password manager like 1Password is a good choice. You will
need it if you set up another machine or need to recover.

With that, your decryption key is no longer sitting next to the repo in another
plaintext file.

Linux and Windows. This post uses macOS Keychain, but the same idea
applies elsewhere. On Linux, secret-tool (backed by libsecret and
GNOME Keyring or KWallet) fills the same role. On Windows, you can use
Credential Manager via PowerShell's Get-StoredCredential /
New-StoredCredential cmdlets. The loading pattern stays the same; only
the key retrieval command changes.

The loading pattern

The subtle part is loader order.

If you want a flag like USE_KEYCHAIN_FOR_DOTX=true to live in .env.local,
your app needs to read .env.local before it decides whether to pull the
decryption key from Keychain.

That means the loader should do this:

Load .env
Load .env.local
Check USE_KEYCHAIN_FOR_DOTX
If enabled, read DOTENV_PRIVATE_KEY_LOCAL_SECRETS from Keychain
Load .env.local.secrets

Here is the core idea in TypeScript:

Open as GitHub Gist

import { execFileSync } from "node:child_process";
import { existsSync } from "node:fs";
import { resolve } from "node:path";
import { config } from "@dotenvx/dotenvx";

export function loadEnv(): void {
  for (const file of [".env", ".env.local"]) {
    const path = resolve(process.cwd(), file);
    if (existsSync(path)) {
      config({ path });
    }
  }

  const localSecretsPath = resolve(process.cwd(), ".env.local.secrets");
  if (!existsSync(localSecretsPath)) {
    return;
  }

  if (process.env.USE_KEYCHAIN_FOR_DOTX === "true") {
    try {
      process.env.DOTENV_PRIVATE_KEY_LOCAL_SECRETS = execFileSync(
        "security",
        [
          "find-generic-password",
          "-a",
          "LOCAL_SECRETS_DOTENVX_KEY",
          "-s",
          "LOCAL_SECRETS_DOTENVX_KEY",
          "-w",
        ],
        { encoding: "utf-8" }
      ).trim();
    } catch (err) {
      throw new Error(
        "Failed to read decryption key from macOS Keychain. " +
          "Make sure the LOCAL_SECRETS_DOTENVX_KEY item exists. " +
          "See scripts/store-keychain-key.sh for setup.",
        { cause: err }
      );
    }
  }

  config({ path: localSecretsPath, overload: true });

  // The private key has done its job. Remove it from the environment so it
  // is not visible in process.env dumps or child process inheritance.
  delete process.env.DOTENV_PRIVATE_KEY_LOCAL_SECRETS;
}

Three notes:

execFileSync will throw on a non-zero exit, so the try/catch above turns a cryptic child-process error into a clear setup instruction
the delete at the end matters: once dotenvx has decrypted the secrets into their individual env vars, the private key has no further purpose; leaving it in process.env means any code that inspects the environment (logging, diagnostics, error reporters) could leak the one key that decrypts the file
do not log even partial key material during startup. That is easy to get wrong when debugging the integration

One thing this does not protect against: once your app is running, the
decrypted secrets are plain strings in process.env. Anyone who can attach a
Node debugger to your process can inspect memory directly.

Cross-process env snooping is more nuanced. On macOS 11+, SIP prevents
processes from reading other processes' environment variables, so this vector
is largely closed on a default macOS install. On Linux, /proc/<pid>/environ
is still readable by any process running as the same user. Either way, this
pattern is about secrets at rest on disk, not secrets in a running process.

Next.js integration

If you are using Next.js, you cannot just call loadEnv() from anywhere and
expect it to work. Next.js has its own env loading built in, and by the time
your application code runs, it has already resolved which variables are
available.

The right place to hook this in is instrumentation.ts (or .js). Next.js
calls the register function exported from this file once when the server
starts, before any routes or middleware run. That makes it the earliest
reliable point to pull secrets from Keychain and inject them into process.env.

// instrumentation.ts
export async function register() {
  const { loadEnv } = await import("./lib/load-env");
  loadEnv();
}

The dynamic import is intentional. It keeps the Keychain and dotenvx logic
out of the client bundle and avoids top-level side effects that could run at
the wrong time.

Make sure instrumentation.ts is at your project root (next to next.config),
and that you are on Next.js 15+ where the instrumentation hook is stable. On
older versions (13.2 through 14.x) it works but requires setting
experimental.instrumentationHook: true in your Next config.

Helper scripts for temporary decrypt/re-encrypt

I also like keeping two tiny helper scripts around so I can temporarily decrypt
the file, edit it, and then re-encrypt it.

#!/usr/bin/env bash
# scripts/decrypt-local-secrets.sh
set -euo pipefail

KEYCHAIN_ITEM_NAME="LOCAL_SECRETS_DOTENVX_KEY"

export DOTENV_PRIVATE_KEY_LOCAL_SECRETS="$(
  security find-generic-password \
    -a "$KEYCHAIN_ITEM_NAME" \
    -s "$KEYCHAIN_ITEM_NAME" \
    -w
)"

pnpm exec dotenvx decrypt -f .env.local.secrets

#!/usr/bin/env bash
# scripts/encrypt-local-secrets.sh
set -euo pipefail

KEYCHAIN_ITEM_NAME="LOCAL_SECRETS_DOTENVX_KEY"

export DOTENV_PRIVATE_KEY_LOCAL_SECRETS="$(
  security find-generic-password \
    -a "$KEYCHAIN_ITEM_NAME" \
    -s "$KEYCHAIN_ITEM_NAME" \
    -w
)"

pnpm exec dotenvx encrypt -f .env.local.secrets

That gives you a simple workflow:

bash scripts/decrypt-local-secrets.sh
# edit .env.local.secrets
bash scripts/encrypt-local-secrets.sh

One risk here: if you decrypt the file, edit it, and forget to re-encrypt,
your secrets are back to sitting in plaintext. A git pre-commit hook can catch
this. Something like:

#!/usr/bin/env bash
# .husky/pre-commit or .git/hooks/pre-commit
if head -c 50 .env.local.secrets 2>/dev/null | grep -qv "^#/"; then
  echo "ERROR: .env.local.secrets appears to be decrypted. Run:"
  echo "  bash scripts/encrypt-local-secrets.sh"
  exit 1
fi

(dotenvx-encrypted files start with a comment header like
#/-------------------[DOTENV]--------------------/, so checking for the
absence of that prefix is a reasonable heuristic.)

Where this helps, and where it doesn't

This pattern helps with:

raising the cost of supply chain attacks that look for .env files
repo-wide local file scraping
accidental plaintext secret exposure in local tooling
reducing how many places secrets live on disk
avoiding accidental exposure during screen sharing and pair programming

It does not solve:

malicious code running inside your process
a debugger attached to your Node process (secrets are in memory as plain strings)
cross-process env snooping on Linux (/proc/<pid>/environ); macOS SIP blocks this since Big Sur, but Linux does not
secrets already exported into your shell
logs or copy/paste leaks
production secret management

Think of it as one useful layer, not as a silver bullet.

A note on screen sharing

If your secrets live in a
plain-text .env.local, it is very easy to accidentally flash them on screen
during a Zoom call, a pair programming session, or a live demo. All it takes
is opening the wrong file, running cat on it, or having your editor preview
it in a sidebar.

With encrypted .env.local.secrets, that file is just opaque ciphertext. Even
if you open it on camera, nobody sees your database credentials or API keys.
The decryption only happens at runtime, in memory, when your app starts, not
when a human or a screen recording is looking at your filesystem.

This is not a reason to adopt the pattern on its own, but it is a nice side
effect that has already saved me at least once.

The developer-experience bar matters

The reason I like this approach is that it is security work people may actually
keep using.

Once set up, the workflow is close to normal local development:

keep config in .env.local
keep secrets in .env.local.secrets
let the app pull the key from Keychain when needed

That is much more likely to stick than a system that feels "more secure" on paper
but creates enough friction that everyone bypasses it.

If you want to adopt this

My suggestions:

Start with local-only encryption, not a big secret-sharing redesign.
Separate non-secret config from secrets first.
Make the Keychain path opt-in with a clear env flag.
Ensure .env.local loads before you evaluate that flag.
Audit helper scripts too, not just the main app boot path.
Back up your decryption key in a password manager before deleting .env.keys.
Add a pre-commit hook to catch unencrypted secrets files.
Never print keys, even partially, while debugging the integration.

That last point deserves repeating.

Security improvements have a way of being partially undone by "temporary"
debugging statements.

Related tools worth looking at

If this pattern feels too lightweight for your needs, or you want something
more structured, there are good adjacent tools in this space.

SOPS is a strong option when you want encrypted files as
a first-class workflow, especially in teams already comfortable with cloud KMS,
age, or GitOps-style config management.

DMNO goes in a different direction: schema-aware config,
tooling around developer experience, and integrations with external secret
stores. Their 1Password plugin
is a good example if you want local development ergonomics tied more directly to
a secrets manager instead of local encrypted .env files.

I do not see these as mutually exclusive with the smaller pattern in this post.
They just sit at different points on the complexity and capability curve.

Closing thought

I do not think local .env files are going away anytime soon.

But I do think the threat model around them has changed.

A small amount of structure, encryption at rest, and OS-managed key storage can
go a surprisingly long way without making local development miserable.

Followup: I also wrote a companion script that scans your machine for plaintext secrets sitting in .env files. It pairs well with this post as a way to find what needs encrypting.
Find Plaintext Secrets Hiding in Your .env Files

Object Oriented Functional Programming or How Can You Use Classes as Redux Reducers

Ustun Ozgur — Mon, 20 Feb 2017 06:24:48 +0000

Note: This article originally appeared Ustun Ozgur's blog on Medium.

TL;DR You can use ImmutableJS Record classes with methods as Redux reducers, combining the best of FP and OOP.
See the final result here: https://gist.github.com/ustun/f55dc03ff3f7a0c169c517b459d59810

In the last decade, functional programming has been steadily gaining
popularity, while object oriented programming is being questioned more
and more. The kingdom of nouns is now being threatened by the kingdom
of verbs, and we can see this revolution best explained in Rich
Hickey's talk Simple Made Easy.

In the JavaScript frontend ecosystem, React broke the last functional
frontier, UI development and ideas from the functional world such as
immutability, higher order functions are now becoming common-place in
the industry.

The principal difference between object oriented programs and
functional programs is their stance on handling data and
state. Objects by their nature encapsulate data, whereas in functional
programs, data is usually separated from the code. One additional
vital difference is that, most OOP systems also incorporate identity
tracking, that is, an object is not only the sum of its state (data)
and methods (or functions in FP world), but also identity.

So,

OOP out of the box gives you identity + state + methods.
FP out of the box gives you data + functions.

Tracking the identity is left as exercise to the reader, which is a
blessing and a curse; and as a consultant and trainer to multiple
companies, the single most source of confusion people face when
transitioning paradigms.

Decoupling

The fundamental idea in analyzing big systems is decoupling and layering. When confronted with state, functional programming basically asks the
following question: What if we would take the three notions,
state, identity and methods and decouple them?

The advantage is that these different parts can be constructed and
assembled separately. The disadvantage is you risk losing the cohesion
of your abstractions.

Functions andÂ Methods

Let's start with methods for example. Most classes act as bags of
methods, so if you have a few methods on your plate, you could
actually have those as different functions that take the primary data
being operated on as the first argument. Effectively, thing.doIt() becomes doIt(thing).

Such functions can obviously take additional arguments, however most
of the time, in a business application setting which follows the
Domain Model pattern, the first argument of the function will be the
domain model we are operating on.

As the number of functions increases though, your program is in a
danger of filling up with lots of functions scattered around. FP
languages do not give much guidance here, effectively you are free to
do whatever you prefer. Again a blessing and a curse.

In an OOP world, where a function goes in is pretty much defined; in
less flexible languages like Java (before Java 8) for example, the
functions belonged to classes.

In a more flexible language like JavaScript though, we could collect
the functions related to a data structure in a module or an object
literal.

For example, if we have 3 different functions operating on a data
structure like Person, we could collect three functions operating on
Person datas as follows:

PersonFunctions = {
Â doThis(person,Â …) {Â … }
Â doThat(person,Â …) {Â … }
Â doBar(person,Â …) {Â … }
}

This is effectively solving the third part of the decoupling process,
namely handling the placement of the methods.

Another alternative here would be to create a JS module (a file
actually) that has these functions at the top-level, as follows:
in person_functions.js
function doThis(person,Â …) {Â ….}
function doThat(person,Â …) {Â ….}
function doBar(person,Â …) {Â ….}

(In a langugage like Clojure, for example, the equivalent would be to put these functions into namespaces.)

State, Data andÂ Identity

As mentioned before, functional programs effectively separate state
(data) and identity. Most OOP systems operate the data in place,
whereas the functional counterparts need to handle both the input and
output of the data explicitly. Hence, in OOP, this keyword offers a convenience to the following 3 steps in a functional program:

aâ€Š–â€Šget data => state as data
bâ€Š–â€Štransform data => some_function(data)
câ€Š–â€Šput the data where you took it. => state = some_function(data)

In OOP world, steps a & c are automatic, if you access the state in
the thing pointed by this keyword. This is the main decoupling here, OOP takes the position that most of the time, you will put the data from where you took it back, where FP takes the position that these three steps could be decoupled.

If you want to track the identity in an FP system, you have to do it
manually, though it is not as laborous as it sounds.

For example, Clojure provides atoms, which effectively are more similar to objects in Java or JavaScript; which enclose the pure data.

Any function call operating on an atom effectively sends the same call to the inner object, and writes the output object back.

Let's say we have an atom that wraps some data.

my_object = atom(data)
swap(my_object, some_function)

effectively becomes three operations:

1- Extract the data from the object.
2- Execute some function on the data.
3- Write the data back into the object.

As a result, if identity tracking is added, a FP system is
equivalent to an OOP system.

Redux

And this is where Redux comes in. Redux is basically advertised as “a
state container”, which wraps your data (state) in an object
(store). And any transformation you do is a transforming function
called “a reducer”.

Excluding the fancy terms like state containment and reducing
operation though, this is effectively just what OOP provides. OOP
provides a container for your data, and provides some methods
(equivalent to functions, reducers) that operate on that data, and put
the result back into the place when the transformation is done.
Hence, Redux reducers are equivalent to traditional Object Oriented
Programming, with the following two differences:

1- It does not give you dispatch by default, so you have to do if/else/switch to select the method to operate on.
2- All the data is modelled as immutable data structures.

So, the obvious question is this: Can we have our cake and eat it too?

That is, how can someone proficient with object modeling reuse his
skills in a Redux application?

The Obligatory TodoÂ App

Let's consider the following transform function for a TodoApp, a reducer. The basic domain modeling is as follows:

You can add, remove todos, toggle todos' completion state, and add a Â temporary todo text that will be added when user presses Â Submit. I'll just implement REMOVE_TODOS so that the code is Â concise.

function todoAppReducer(state={todos:[], newTodo: â€˜'}, action) {
    switch (action.type) {
    case â€˜REMOVE_TODO':
            return {…state, todos: state.todos.filter(todo=>todo.description!= action.payload.description)}
    case â€˜ADD_TODO':
    case â€˜TOGGLE_TODO':
    case â€˜ADD_TEMP_TODO':
    }
}

The first refactoring results in the following, where we replace dispatch functions with an object bag of methods.

function todoAppReducer(state={todos:[], newTodo: â€˜'}, action) {
    methods = {
    REMOVE_TODO: function (payload) return {…state, todos: state.todos.filter(todo=>todo.description != payload.description)},
    ADD_TODO: function () …,
    TOGGLE_TODO: function () …,
    ADD_TEMP_TODO: function ()
    }

    return methods[action.type](action.payload)
}

Now, since the functions in methods object are inside the main function, all of them can access the variable named state. If we take the methods object out those, we have to pass the state explicitly.

methods = {
    REMOVE_TODO: function (state, payload) return {…state, todos: state.todos.filter(todo=>todo.description != payload.description)},
    ADD_TODO: function (state, payload) …,
    TOGGLE_TODO: function (state, payload) …,
    ADD_TEMP_TODO: function (state, payload)
}

function todoAppReducer(state={todos:[], newTodo: â€˜'}, action) {
    return methods[action.type](state, action.payload)
}

Now, the object literal methods is starting to look more like a
traditional bag of objects, a class. First, let's move them inside a
proper class, where we do not make use of this for now. Effectively,
this is a class of static methods that take â€˜state' as first variable.

class Todo {
     REMOVE_TODO(state, payload) {
     return {…state, todos: state.todos.filter(todo=>todo.description != payload.description)};
    }
    ADD_TODO(state, payload) {
    }
}

At this stage, we are almost midway between FP and OOP. Closer to FP in spirit, and closer to OOP in look. The generation of immutable values is quite ugly though, using spread operator and various tricks that will irk most newcomers.
Enter ImmutableJS library, which makes these transformations natural. Getting a new version of an immutable object with all the fields, except one intact is as simple as just setting that field.
For example, let's say we have object A, and want to get object B, but with name set to foo.

B = A.set(â€˜name', â€˜foo')

Effectively, as an OOP programmer, you can think of ImmutableJS as taking a clone of your current object without defining cloning operation and setting the different values.
Want to have the same as in object A, but with name â€˜foo', and surname â€˜bar'?
You could do it by setting those in succession:

A.set(â€˜name', â€˜foo').set(â€˜surname', â€˜bar')

or in one step by merging the second object like:

A.merge({name: â€˜foo', surname: â€˜bar'})

So, transforming our previous class to use ImmutableJs, we get the following:

class Todo {

    REMOVE_TODO(state, payload) {
    return state.set(â€˜todos', state.todos.filter(todo=>todo.get(â€˜description') != payload.description));
    }

    ADD_TODO(state, payload) {
    }
}

function todoAppReducer(state=Immutable.fromJS({todos:[], newTodo: â€˜'}), action) {
    return Todo[action.type](state, action.payload)
}

You will see that we are still passing state explicitly, whereas we would just use this to pass state explicitly in an OOP application.
Enter Immutable Records, which give you the best of both worlds, where you can define methods that operate on this.
Let's convert our Todo class to make use of Immutable Records.

class Todo extends Immutable.Record({todos:Immutable.List(), newTodo: â€˜'}){
    REMOVE_TODO(payload) {
    return this.set(â€˜todos', state.todos.filter(todo=>todo.get(â€˜description')!= payload.description));
    }

    ADD_TODO(payload) {

    }
}

function todoAppReducer(state=new Todo(), action) {
    return state[action.type](action.payload)
}

See where we are going with this? Just a few cosmetic steps left.

1- What to do about methods we don't recognize? In JS, this is easy, we could just access the proper state[action.type] and check whether it is a function or not.

2- Ugly method names: In Redux apps, event names are usually CONSTANT_CASED and we want them camelCames. The transformation is easy thanks to lodash.camelcase.

Now, let's extract the part where we take an Immutable Record class and we produce a compatible Redux reducer.

class Todo extends Immutable.Record({todos:Immutable.List(), newTodo: ''}) {

    removeTodo(payload) {
    return this.set(â€˜todos', state.todos.filter(todo=>todo.get(â€˜description')!= payload.description));
    }

    addTodo(payload) {
    }
}
function todoAppReducer(state=new Todo(), action) {
    var fn = state[camelcase(action.type)]
    if (fn) {
    return state[camelcase(action.payload)](action)
    } else {
    // we don't recognize the method, return current state.
    return state;
    }
}

Final Product:
You can get the final version of this pattern here on Github

var camelCase = require('lodash.camelcase');
const {Map, Record, List} = require('immutable');

class Todo extends Record({ description: null, completed: false }) {
    toggle() {
        return this.set('completed', !this.completed);
    }
}

const InitialTodoApp = Record({
    newTodo: '',
    todos: List(),
    activeFilter: ''
});


class TodoApp extends InitialTodoApp {

    init(data) {
        return this.merge(data);
    }

    // action methods: kind of like IBActions

    setTempTextAction({value}) {
        return this.setNewTodo(value);
    }

    removeTodoAction({description}) {
        return this.removeTodo(description);
    }

    addTodoAction() {
        return this.addTodo();
    }

    // other methods

    setNewTodo(newTodo) {
        return this.set('newTodo', newTodo);
    }

    addTodo() {
        return this.addTodoFromDescription(this.newTodo).resetNewTodo();
    }

    resetNewTodo() {
        return this.set('newTodo', '');
    }

    addTodoFromDescription(description) {
        const newTodos = this.todos.push(new Todo({ description: description }));
        return this.setTodos(newTodos);
    }

    removeTodo(description) {
        const newTodos = this.todos.filter(todo => todo.description != description);
        return this.setTodos(newTodos);
    }

    setTodos(todos) {
        return this.set('todos', todos);
    }

    setTodosFromJS(todosJS) {
        const todos = todosJS.map(todoJS => new Todo(todoJS));
        return this.setTodos(todos);
    }

    incompleteTodos() {
        return this.todos.filter(todo => !todo.completed);
    }

    nIncompleteTodos() {
        return this.incompleteTodos().length;
    }

    completeTodos() {
        return this.todos.filter(todo => todo.completed);
    }

    nCompleteTodos() {
        return this.completeTodos().length;
    }

    allTodos() {
        return this.todos;
    }

    toggleTodo({description}) {
        var newTodos = this.todos.map(todo => todo.description != description ? todo : todo.toggle())
        return this.setTodos(newTodos);
    }

    describe() {
        console.log(JSON.stringify(this.toJS(), null, 4));
        console.log("incomplete todos", this.nIncompleteTodos());
    }
}

function reducerFromRecordClass(klass) {
    return function (state = new klass(), action) {
        var fn = state[camelCase(action.type + '_ACTION')];
        if (fn) {
            return state[camelCase(action.type + '_ACTION')](action);
        } else {
            if (state[camelCase(action.type)]) {
                console.warn('You tried to call an action method, but no such action method provided.', action.type)
            }
            return state;
        }

    }
}


const todoAppReducer = reducerFromRecordClass(TodoApp);

export default todoAppReducer;
// main();

Compared to a traditional OOP application, we can observe a few things:

1- All setters have to return a new object.
2- Identity tracking is done by redux.
3- Redux actions are suffixed by “action (this is completely optional, just provided to separated methods that are invoked via redux from normal methods. Redux methods simply delegate to normal class methods.)

Other than that,it is pretty much the best of both functional and object oriented worlds.Unlike most Redux applications which operate on an amorph, unnamed
data structure called “state”, we have a real domain model which eases
our mental data abstraction capabilities. We can also reuse this model
elsewhere easily and even use other OOP techniques like inheritance to
derive new classes.

Unlike most OOP applications, this operates on immutable data as in FP
and hence solves the tight coupling between state and identity.
In this particular instance, identity tracking is left to Redux, but a
simple stateful wrapper like a Clojure atom will bring you the
identity tracking benefits of OOP.

Acknowledgments:

Thanks to Ahmet Akilli from T2 Yazilim for introducing me to JumpState, which basically implements the same idea, but without using Immutable Records. See more discussion here: https://medium.com/@machnicki/why-redux-is-not-so-easy-some-alternatives-24816d5ad22d#.912ks1hij

Conclusion

I hope this article provides guidance to you as you utilize hybrid paradigms in developing your applications. We believe FP and OOP paradigms can co-exist to build powerful products.

If you need assistance, consulting and training, feel free to drop us a line at SkyScraper.Tech (contact@skyscraper.tech) and we'll be pleased to help.
We provide consultancy services, where we lead teams, and also
write code. We also provide skeletons so that our customers' existing teams can continue from a good foundation.

We support a number of platforms, ranging from Django to nodejs to
Clojure apps, depending on the requirements. We also give trainings
mainly on JavaScript (backend and frontend), but also on other
platforms we support.

See http://skyscraper.tech for more info.
Discuss this article on HackerNews: https://news.ycombinator.com/item?id=13578656

DEV Community: Ustun Ozgur

A Practical Guide to Moving from AWS App Runner to ECS Express Mode

Start with the Right Mental Model

What Usually Carries Over Cleanly

What Changes in ECS Express Mode

Observability changes: X-Ray is no longer built-in

Cost changes: the ALB you did not used to pay for

The Migration Plan I Recommend

1. Inventory the App Runner service before changing anything

2. Preserve the image pipeline

3. Bring up ECS Express in parallel

4. Rebuild the edge deliberately

5. Shift traffic gradually

6. Re-verify operator workflows before deleting App Runner

The Most Common Pitfalls

Public health checks can lie

Shared ALBs reduce cost and increase coupling

Terraform will not always tell you everything during plan

Secret references and secret values are not the same thing

Do not let the migration silently change deploy contracts

When ECS Express Mode Is a Good Fit

When You May Want Standard ECS Instead

A Short Acceptance Checklist

Final Advice

Further Reading

Terraform HCL for Developers: Why It Feels Familiar and Strange

1. It's a graph, not a script

2. HCL is built from arguments and blocks

3. The expression language is where HCL feels Pythonic

4. Instance identity matters more than iteration

5. State is the hidden half of the model

6. Where the chimera gets awkward

Conclusion

Find Plaintext Secrets Hiding in Your .env Files

The problem with "just gitignore it"

The script

Usage

What to do with the results

Running it periodically

Design decisions

The full script

Closing thought

A Small Hardening Trick for .env.local: dotenvx + OS Keychain

The setup

Why bother with the extra steps?

Move the key into macOS Keychain

The loading pattern

Next.js integration

Helper scripts for temporary decrypt/re-encrypt

Where this helps, and where it doesn't

A note on screen sharing

The developer-experience bar matters

If you want to adopt this

Related tools worth looking at

Closing thought

Object Oriented Functional Programming or How Can You Use Classes as Redux Reducers