Change an env var once.
Every service has it in a second.

Rotate a burned proxy or a leaked API key across your whole fleet from one place, without a redeploy. Values and names are encrypted on your machine, so we only ever hold ciphertext.

Get early accessSee how it works
  • No redeploys
  • Zero-knowledge
  • One static binary
PROXY_SERVER=http://proxy-a.example:8000
production/35 processes
  • api

    proxy-a

  • api-eu

    proxy-a

  • api-us

    proxy-a

  • gateway

    proxy-a

  • auth

    proxy-a

  • billing

    proxy-a

  • search

    proxy-a

  • scrape-us-1

    proxy-a

  • scrape-us-2

    proxy-a

  • scrape-us-3

    proxy-a

  • scrape-eu-1

    proxy-a

  • scrape-eu-2

    proxy-a

  • scrape-eu-3

    proxy-a

  • scrape-ap-1

    proxy-a

  • worker-1

    proxy-a

  • worker-2

    proxy-a

  • worker-3

    proxy-a

  • worker-4

    proxy-a

  • worker-5

    proxy-a

  • worker-6

    proxy-a

  • cron

    proxy-a

  • ingest

    proxy-a

  • enrich

    proxy-a

  • dedupe

    proxy-a

  • export

    proxy-a

  • webhooks

    proxy-a

  • mailer

    proxy-a

  • notifier

    proxy-a

  • thumbs

    proxy-a

  • pdf

    proxy-a

  • reports

    proxy-a

  • metrics

    proxy-a

  • admin

    proxy-a

  • sitemap

    proxy-a

  • monitor

    proxy-a

35/35

have the new value

1.1 s

change to last process

0

redeploys

Illustration: one change, 35 processes. The ones marked with a circular arrow restart; the rest read it on their next request.

A proxy dies. Now you're redeploying 35 apps.

The proxy URL lives in 35 env files. Swapping it means 35 edits, 35 builds and 35 rollouts, while requests keep failing on the dead one. With Dynv it is one change, and every process has it before you've closed the tab.

  • Requests fail until the last rollout finishes.
  • Someone forgets service 23, and nobody notices until Monday.
  • The new key gets pasted into 35 CI settings pages.

Edit env, rebuild, roll out

35 redeploys

Change it in Dynv

about 1 second

You notice the dead proxyEvery service is on the new one

Three steps. One is a single line.

  1. 1

    Add your variables

    In the dashboard. Names and values are encrypted in your browser before anything is sent.

  2. 2

    Start each service through Dynv

    Give it its own token and prefix the start command with dynv run --. For values you want without a restart, read them through the SDK.

  3. 3

    Change a value

    It reaches every running process that uses it in about a second. No pipeline, no rollout.

Any Docker image, Coolify, or a bare hostsh
# this process's own token and id, from the dashboard
$ export DYNV_URL=https://dynv.example
$ export DYNV_PROCESS=EXAMPLEproc00000
$ export DYNV_TOKEN=dynv_pt_EXAMPLE0000000.••••••••
$ dynv run -- node dist/api.js
Hot values, no restartsrc/fetch.ts
import { dynv } from "@dynv/sdk";

// read on every request: always the current value
const proxy = dynv.get("PROXY_SERVER");

// or react the moment something changes
dynv.on("change", () => pool.reset());

Hot or restart. You choose per variable.

Some values can change under a running process. Some are read once at boot. Dynv handles both, and you can mix them in the same service.

Hot

dynv.get("PROXY_SERVER")
changeproxy-aproxy-b

The process never stops. The next request reads the new value. Good for proxies, upstream URLs, API keys, rate limits and flags: anything you read per request.

Restart

dynv run -- node dist/api.js
changeold envnew env

Dynv supervises the process and restarts it with the new env. No code changes. Good for database URLs, anything read once at boot, and apps you can't touch.

We can't read your variables. Not won't: can't.

Names and values are encrypted on your machine or in your browser with AES-256-GCM, using keys derived from your tokens, and signed with Ed25519. Your tokens never reach us. What we store is the right-hand side.

What you see

In your browser, your terminal, your process

PROXY_SERVER
http://proxy.example:8000
SEARCH_API_KEY
example-key-not-real-0000
RATE_LIMIT_PER_MIN
600

What our server sees

The same three variables

q8Zt1Lr0vW3nE2xAo9cK7bYpQm4sUd6HfJ…

Xk2Pa9Vb0LmR7cT1zQw3NyE5gS8uHd4jIo…

Fh6Ur1Yt3Ze0Lq9Xm2Cv7Bn4Ka8Sd5WpGj…

What we do see

  • Random ids for your account, processes and tokens.
  • Ciphertext, padded to 1 KB steps so its size gives away little.
  • How many processes and tokens you have, and when each one changes.
  • When each process fetches, and from which IP address. That is your audit log.
  • When each token was last seen.

What we never see

  • Variable names or values.
  • Your tokens. We keep a hash of a key derived from each one, which proves who is asking but opens nothing.

What if Dynv is breached?

An attacker gets what we have: ids, ciphertext, IP addresses and timestamps. There is no key on our side to decrypt it with. Every update is signed with your account's Ed25519 key, and each process receives the matching public key sealed to its own token. An update that doesn't verify is refused, and the process keeps its last good env.

What this can't protect: a stolen master token, or a host that is already compromised. A process can always read its own env.

One token per process. Revoke one, the rest keep running.

Each service sees only its own variables

The scraper's token opens the scraper's env and nothing else. If one box is compromised, the blast radius is that one service.

  • apiPROXY_SERVER, SEARCH_API_KEY, +6active
  • scrape-us-1PROXY_SERVER, RATE_LIMIT_PER_MINactive
  • scrape-us-3PROXY_SERVER, RATE_LIMIT_PER_MINrevoked
  • billingPAYMENTS_KEY, DATABASE_URLactive

Keys rotate when you revoke

Revoking a token rotates the keys behind it automatically. The revoked process can't open anything that changes afterwards, and nobody else has to update a thing.

1 of 35

processes touched by a revoke

Every fetch and every change, logged

Who asked, from where, when, and which version they got

  1. 14:02:11fetchworker-3v42
  2. 14:02:11fetchscrape-eu-2v42
  3. 14:02:10changeownerv41 → v42
  4. 13:58:47revokescrape-us-3keys rotated
  5. 13:41:02fetchapiv41

If we're down, your services aren't.

Dynv sits beside your process, never in front of your traffic. Losing it means changes wait, not outages.

Falls back to the env you already have
If Dynv is unreachable when a process starts, it runs on its existing environment and catches up when we are back.
Changes in about a second
Each process holds a long-poll watch open and wakes the moment a change lands. Where long-polling is blocked, it falls back to polling.
One small static binary
Written in Rust, with no runtime dependencies. Copy it into any Docker image, run it on Coolify or on a bare host.

Questions teams ask us.

Something else? Write to us.

Do I have to change my code?

No. Wrap your start command with dynv run and it restarts the process with the new env whenever a value changes. You only add the TypeScript SDK for variables you want hot, read on the next request with no restart.

Which languages does it work with?

dynv run works with anything that reads environment variables, which is everything. The hot SDK is TypeScript today.

What happens if Dynv is down?

Your process keeps running. If it starts while Dynv is unreachable, it uses the env it already has, and it picks up changes once Dynv is back.

Can you read my variables?

No. Names and values are encrypted on your machine or in your browser before they reach us, with keys derived from tokens we never receive. We store ciphertext and could not decrypt it if we tried.

How fast does a change arrive?

About a second. Each process holds a long-poll watch open and wakes as soon as a change lands. If a network blocks long-polling, it falls back to regular polling.

How is this different from a secrets manager?

Secrets managers store values and usually supply them when a process starts or a deploy runs. Dynv is built for changing values while processes run: a change reaches each running process in about a second, hot or with a supervised restart. Names and values are encrypted on your side, so we store only ciphertext.

How much does it cost?

Pricing is not public yet. We are onboarding early teams by hand. Ask for early access and we will talk it through.

What if I lose my master token?

We can't recover a lost master token; that's what zero-knowledge means. Create a second master token as a recovery kit and store it offline.

What is next?

Signed, versioned shared code modules, delivered to your processes the same way variables are. Coming soon.

Stop redeploying to change a string.

We are onboarding early teams by hand. Tell us how many services you run and what you rotate, and we'll set you up.

Get early accessTalk to us