Repository navigation
Railway template generates invalid ENCRYPTION_KEY (should be 64-char hex string) #6246
Description
Description
Deploying Sim using the official Railway template generates an ENCRYPTION_KEY that is not compatible with Sim.
The generated value looks like:
9U8FH7siuiZFhVbe--pf...
However, when attempting to save Workspace Secrets, the backend returns:
ENCRYPTION_KEY must be set to a 64-character hex string
and the request fails with HTTP 500.
Expected
The Railway template should generate ENCRYPTION_KEY as:
openssl rand -hex 32
which produces a 64-character hexadecimal string.
Actual
The generated value appears to be a generic secret (base64/url-safe), not a hex string.
Steps to reproduce
- Deploy using the official Railway template.
- Open Settings → Secrets.
- Add TEST_SECRET=hello.
- Click Save.
- Observe HTTP 500.
Railway log:
ENCRYPTION_KEY must be set to a 64-character hex string
Workaround
Generate a new key with:
openssl rand -hex 32
Replace ENCRYPTION_KEY in Railway and redeploy.
Activity
eeshsaxena commentedon Aug 7, 2026
The mismatch is base64 vs hex. Railway's template secret generator emits a URL-safe base64 string (the
--in9U8FH7siuiZFhVbe--pf...is the tell), whereas Sim validatesENCRYPTION_KEYas a 64-character hex string (32 bytes, i.e.openssl rand -hex 32). So the value has enough entropy but the wrong alphabet and length, and the first code path that actually uses it (saving a workspace secret) rejects it, which is the HTTP 500.Worth noting the repo's own Docker self-hosting docs already generate it correctly (
apps/docs/content/docs/en/platform/self-hosting/index.mdx:ENCRYPTION_KEY=$(openssl rand -hex 32)); it is specifically the Railway template that differs.Two ways to fix it on the template side:
secret()generator, pin it to a hex alphabet (Railway'ssecret()takes an optional alphabet), e.g.${{ secret(64, "0123456789abcdef") }}, so it emits a 64-char hex string directly.openssl rand -hex 32.Happy to open a small docs PR adding a note to the Railway/self-hosting section ("if saving secrets fails with
ENCRYPTION_KEY must be set to a 64-character hex string, regenerate it withopenssl rand -hex 32and set it in the service variables") so anyone hitting this from the template has the fix inline, if that would be useful.Ashar086 commentedon Sep 12, 2026
Hi team,
Since PR #6530 only added a documentation workaround, the underlying Railway template configuration still generates an incompatible key format out of the box. I'd love to fix the root cause by updating the template to enforce the hex alphabet:
${{ secret(64, "0123456789abcdef") }}.Alternatively, if someone is already looking at the template, I am also available to help look into the Parallel Block concurrency limit (#4903).
Please let me know which one I should pick up. Thanks!
sahooarnav2007-gif commentedon Oct 26, 2026
Hi @maintainers, I would love to take this up!
The issue is that the Railway template currently uses the default ${{ secret() }} generator, which outputs a URL-safe alphanumeric string instead of hexadecimal.
In Railway templates, we can constrain this by updating the variable generator to use a 64-character hex alphabet:
env
ENCRYPTION_KEY=${{secret(64, "abcdef0123456789")}}
Could you please assign this issue to me so I can open a PR with the fix? Thanks!