I run Post-Mission Planner (Holland Labs LLC), an iOS planner app whose API, Postgres database and admin tools run on Railway. After the October 21 security disclosure, we rotated every secret and reviewed our setup. We’d like to stay on Railway, and a few changes to how variables and secrets work would make that much easier to justify.

In order of importance to us:

Workload identity (OIDC tokens for services). Let each service get a short-lived, signed identity token it can exchange with AWS, Google Cloud or Azure. We could then keep encryption keys in AWS KMS or Google Cloud KMS and grant access to a specific Railway service, with no long-lived cloud credentials stored in Railway variables. This is how GitHub Actions and most major platforms handle it, and it would have limited the impact of the October incident for us.

Customer-managed keys for variables (bring your own KMS). An option to have a project’s variables encrypted with a key in our own KMS, so they can’t be decrypted without our key and every use is recorded in our own audit log.

An audit log of secret access. A per-project record of who or what read or changed each variable, including from the API, CLI and dashboard, with a way to export it.

Scoped, read-only API tokens. Today a project token can deploy and change settings. Read-only tokens, and tokens limited to particular services or actions, would let us give monitoring tools or contractors only what they need.

If any of these are on the roadmap, we’d be glad to try early versions and give feedback.

Thanks,

Will Holland

Holland Labs LLC — Post-Mission Planner

[email protected]