Railway Sealed Variables Still Reach Your Build (Diagram)

Sealing a Railway variable takes away every way a person can read it back. It takes away none of the ways your code uses it. The dashboard row turns into dots, and the build and the running service carry on receiving the same plaintext they always did.

That gap is fine as long as you know it is there. It bites when the dots get read as "this secret is safe now", which is what the dashboard visually suggests.

Reading the diagram

Start at the grey box at the top. It is one sealed variable, STRIPE_SECRET_KEY, and every arrow below it is a place the value can or cannot go.

Left, dotted: you and your team. This is the only path sealing cuts. Railway's docs put it as a value that "is never visible in the UI nor can it be retrieved via the API", and the CLI will not print it either. The line is dotted because nothing crosses it. It is also grey rather than green, because blocking a person is not the same as protecting the value: the people on your team were never the main way a key escapes.

Middle: the build. The value arrives as plaintext in process.env, because Railway injects sealed variables into builds. While the build runs, so does npm install, and that runs every postinstall script in your dependency tree as ordinary code. Green here means server-side, out of a visitor's reach, not out of a compromised package's reach.

Right: the running deployment. Same plaintext, same process.env. Sealing does not touch what your code does with it next, so a console.log(process.env) or an error tracker that attaches environment context will write the value somewhere else, under somebody else's retention policy.

Bottom, the red edge: your JavaScript bundle. This is the one that turns a server-side secret into a public one. If the variable's name starts with VITE_ or NEXT_PUBLIC_, the bundler copies the value into the client files at build time. Every visitor downloads it. The box is red because anyone can read it, and the edge is the only emphasised one because it is the mistake that costs money.

What to do with it

Seal live credentials anyway. Closing the read-back path is worth it. Then handle the other three arrows yourself: keep credentials the build does not need off the build side, keep process.env out of log and error calls, and never give a secret a VITE_ or NEXT_PUBLIC_ name. The full walkthrough, including a one-line bundle check, is in Railway Secrets: How Sealed Variables Work and What They Miss.

The Mermaid source

Copy this and swap in your own variable name.

---
title: "Sealing hides a secret from people, not code"
---
flowchart TB
    V["Sealed variable<br/><code>STRIPE_SECRET_KEY</code>"]

    H["You and your team<br/>dashboard, API, CLI"]
    B["Build<br/>every install script can read it"]
    R["Running deployment<br/>logs and error trackers catch it"]

    J["Your JavaScript bundle<br/>readable by every visitor"]

    V -.->|"hidden: no read path"| H
    V -->|"plaintext in <code>process.env</code>"| B
    V -->|"plaintext in <code>process.env</code>"| R
    B -->|"<code>VITE_</code> or <code>NEXT_PUBLIC_</code><br/><b>inlined as plain text</b>"| J

    classDef private fill:#ecfdf5,stroke:#10b981,stroke-width:2px,color:#1c1917
    classDef public fill:#fef2f2,stroke:#ef4444,stroke-width:2px,color:#1c1917
    classDef store fill:#f5f5f4,stroke:#57534e,stroke-width:2px,color:#1c1917

    class V,H store
    class B,R private
    class J public

    linkStyle 3 stroke:#ef4444,stroke-width:3px