Skip to portfolio content
Francis Glenn D. Hernandez
All case studies
Internal developer platform · Secret management

Replacing Doppler with Monosg

I designed, built, and migrated an internal secrets platform used by 25 developers across every company repository—reducing projected spend from $525 to less than $5 per month.

active developers
25
repositories migrated
18
projected cost reduction
>99%
monthly infrastructure cost
<$5
01 · Context

A small-team tool became a scaling constraint

When I joined Oboda in September 2024, the engineering team had four developers and one main repository. As the company added enterprise clients, each isolated application introduced more environments and more secret projects. Today, 9 enterprise clients—and a growing pipeline—are supported across an engineering workspace that has expanded to 18 repositories and 25 developers.

Doppler's project limit forced a choice: combine unrelated client secrets, or move to its Team plan at $21 per user per month. At 25 developers, that plan was projected to cost $525 per month, or $6,300 per year.

02 · Constraints

The replacement had to reduce friction, not move it

  • Use existing company Google accounts for authentication.

  • Keep Google Secret Manager as the source of truth.

  • Avoid writing project secrets to local .env files.

  • Give every repository the same setup and execution workflow.

  • Work on developer machines and headless environments.

03 · Workflow evolution

Preserve the workflow, remove the persistent secret files

Doppler already gave developers a convenient setup-and-run pattern. When project limits became a problem, I first moved secrets into Google Secret Manager and wrote pull and push scripts. The developer experience stayed familiar, but every run required another script and materialized the secret bundle in a local .env file.

Doppler
doppler setup -p oboda-app -c stg && doppler run -- next dev
Interim scripts
sh pull-secrets.sh && dotenv -e .env.development.local -- next dev
Monosg
monosg setup -p oboda-app -c stg && monosg run -- next dev

Developers described the migration as “as if nothing had happened.” The command shape remained familiar while the tedious pull step and persistent local secret file disappeared.

04 · Solution

A thin developer layer over Google Secret Manager

Monosg does not replace the underlying managed secret store. Google Secret Manager remains the source of truth; Monosg provides the company-specific authentication, conventions, and command-line workflow around it.

Developers authenticate with a company Google account, configure a repository once, and launch any command through the CLI. The API retrieves the matching environment bundle, and the CLI injects it into the child process without generating a project .env file. Enterprise applications use local, dev_local, dev, prd_local, and prd environments; the main application also supports staging and release variants.

  1. 01
    Authenticate once
    monosg auth login
  2. 02
    Configure the repository
    monosg setup -p myapp -c prd_local
  3. 03
    Run any command
    monosg run -- npm start
Monosg system architectureA developer uses the Monosg CLI, authenticates through Google OAuth, and requests secrets from the Monosg API. The API stores token state in Firestore and reads environment bundles from Google Secret Manager. The CLI injects returned values into a child process.Developer workstationMonosg control planeGoogle CloudMonosg CLIDeveloper interfaceMonosg APICloud Run · ExpressGoogle OAuth@oboda.ai identityFirestoreSession stateSecret ManagerEnvironment bundlesChild processSecrets in process envrequestauthenticatesession statefetch bundlesecrets over HTTPSinject into env

The API is the access layer; Google Secret Manager remains the system of record. Secret values return to the CLI over HTTPS and exist in the launched process environment rather than a generated .env file.

05 · Rollout

From one repository to complete migration

  1. 01

    The original setup

    When I joined in September 2024, four developers worked primarily in oboda-app. Doppler's project limits were not yet a meaningful constraint.

  2. 02

    Enterprise growth

    New enterprise clients introduced isolated applications and multiple environments. The team grew to 13 developers, and the number of secret projects exceeded the plan limit.

  3. 03

    Build and migration

    I built Monosg in two weeks and released it in June 2026. I migrated the enterprise applications first, then moved oboda-app after the team had reached 13 Doppler users.

  4. 04

    Full adoption

    Monosg now serves all 25 developers and all 18 repositories. Doppler has been removed from the company workflow.

06 · Results

Full adoption at a fraction of the projected cost

Projected Doppler Team plan

$525/month

25 users at $21 per user, equivalent to $6,300 per year.

Current Monosg infrastructure

Less than $5/month

Less than $60 per year, saving at least $6,240 annually in projected subscription spend.

All 18 repositories and all 25 developers now use Monosg. The migration removed Doppler from the company workflow and eliminated its project-count constraint.

Removing generated .env files also reduced persistent secret exposure: secrets are no longer left behind for local tools or coding agents to discover. Offboarding can stop future retrieval once Monosg sessions are revoked, although no system can claw back values a user previously copied or printed.

07 · Engineering judgment

The tradeoff: lower spend, greater ownership

The cost reduction came with responsibility for a security-critical internal service. Monosg owns the authentication flow, token lifecycle, access policy, monitoring, and operational reliability that a hosted platform would otherwise provide.

The current system restricts access to authenticated company accounts and is designed not to log or write secret values to project files. The next phase focuses more generally on stronger access controls, session lifecycle hardening, abuse protection, and reliability instrumentation.