Keep the app on Railway. Keep its API keys outside Railway.

How-to·21 October 2026

You should be able to choose where an application runs without giving that platform custody of every upstream API key it uses. Seekrit's credential proxy makes that possible for supported HTTP integrations, provided the proxy's decryption authority stays outside the application's hosting platform.

Railway's preliminary October 21, 2026 disclosure reported possible exposure of customer environment variables, including some decrypted contents. It recommended credential rotation and log review. This guide responds to that risk; it does not reconstruct the attack or claim Seekrit could have prevented the platform breach.

Pick the protection you actually need

Three Seekrit setups have different consequences:

Railway sync is a distribution feature. Use it when you want the destination to receive the values. It is not the setup to choose when the goal is to keep those values outside Railway.

Runtime injection: useful, with a clear limit

If you trust the application runtime with its credentials and want to avoid maintaining individual provider keys in platform variables, install seekrit-run in your runtime image and configure your start command:

seekrit-run --no-env-file -- node server.js

Replace node server.js with your application's command. Supply a service token through SEEKRIT_TOKEN, scoped to the application environment it needs. Keep development and production separate and review any composed group grants.

The launcher resolves encrypted values, decrypts locally, and starts the application with them in its environment. Do this at runtime, not during an image build. Existing process variables take precedence over resolved values, so remove obsolete provider-key variables when cutting over.

Also validate required secrets in application startup. The launcher is best-effort: if resolution fails, it warns and still starts the command without the managed values. An application that requires a credential should refuse to serve requests when it is missing.

This setup is convenient, but the token is sensitive decryption material. Putting it in Railway's variables does not protect its granted secrets from an attacker who obtains that token. Choose the next design when that is the risk you want to address.

Put the broker across the boundary

Run seekrit-proxy in infrastructure administered separately from Railway. Keep its SEEKRIT_TOKEN, configuration, and deployment credentials there too. If Railway-held credentials can administer that infrastructure, the separation is incomplete.

A narrowly scoped reverse-proxy route might look like this:

listen = "127.0.0.1:8080"

[[route]]
prefix = "/openai"
upstream = "https://api.openai.com"
allow = ["OPENAI_API_KEY"]
methods = ["POST"]
paths = ["/v1/responses"]

This example permits only the Responses endpoint. Add another path only when your application needs it. Omitted method or path constraints allow any method or path; the restrictions in the example are deliberate. The proxy checks the route and substitutes the allowed secret into outbound requests. See the proxy guide for installation, policy, and response scrubbing.

Keep that listener private behind an authenticated TLS gateway or a protected network connection. This TOML config is not a complete remote-access setup. You must supply caller authentication and authorization at the boundary; do not expose the listener as an unauthenticated public endpoint. The placeholder does not authenticate the caller. If a gateway uses a separate authentication header, strip that header before forwarding upstream.

Once that boundary exists, an application configured for this route can use:

OPENAI_BASE_URL=https://broker.example.com/openai/v1
OPENAI_API_KEY='{{seekrit:OPENAI_API_KEY}}'

broker.example.com represents your protected gateway. Configure your HTTP client or network layer to authenticate to it separately; these two variables alone do not do that. Store the real OPENAI_API_KEY in Seekrit and grant it only to the broker's token. Neither the real key nor that token belongs in the Railway service.

Now a read of the application's variables yields a placeholder and whatever limited broker access the application holds. It does not yield the upstream key. Someone who steals broker access may still invoke allowed operations, so apply usage limits and provider budgets where available, and record requests at the gateway. Restricting a path does not validate every request body or make every action on that path safe.

Cut over with fresh credentials

Treat this as a credential change as well as a deployment change:

1. Inventory provider keys, database credentials, registry credentials, and any Seekrit tokens that were stored on the affected platform. Follow Railway's guidance while its investigation continues.
2. Create replacement upstream credentials with the permissions the workload needs. Put brokered keys in Seekrit and grant them to the external broker.
3. Test the protected route: an authorized request should work; an unauthenticated caller, unapproved operation, or unapproved secret should be denied. Use disposable credentials for these checks.
4. Move application traffic to the new path when deployment is available. Remove superseded variables and disable any sync binding that would copy the keys back. Disabling sync does not itself prove the destination copies are gone; verify their removal.
5. Revoke old credentials at their issuing providers and review their usage. If continued exposure makes waiting unsafe, revoke first and accept the service interruption rather than treating a deployment pause as protection.

A leaked Seekrit service token also needs revocation and rotation of the affected environment keys. Neither action can recall plaintext already retrieved; rotate exposed upstream credentials as well.

Direct database connections and private image pulls need separate plans. This HTTP route does not broker them. Document those remaining credentials instead of treating the whole application as protected after one API moves.

Start with one valuable HTTP integration. Keep the app where you want to run it, and give it permission to perform the requests it needs while Seekrit's broker holds the key elsewhere.