#Railway fix

1 messages Ā· Page 1 of 1 (latest)

silver hazel
#

Hey

static plumeBOT
sudden wedgeBOT
#

Hey, whatā€™s up? What are you running into with Railway? šŸ¦

silver hazel
#

logs; Config invalid
File: /data/.openclaw/openclaw.json
Problem:

  • channels.discord.streaming: Invalid input (allowed: true, false, "off", "partial", "block", "progress")
sudden wedgeBOT
#

That error means the value at channels.discord.streaming is the wrong shape for the build youā€™re running.

For your current validator, it wants a scalar there, for example:

{
  "channels": {
    "discord": {
      "streaming": "partial"
    }
  }
}

Valid values are exactly:

  • true
#
  • false
  • "off"
  • "partial"
  • "block"
  • "progress"

So if you currently have something like:

"streaming": { "mode": "partial" }

change it to:

"streaming": "partial"
# 
openclaw doctor --fix

That often repairs/migrates config automatically.

silver hazel
#

This issue we fixed otherday too now again when i did a redeploy of repo, also the version gets back to 2026.3.13.

Itā€™s because i first setup using a railway template and the template owner hasnā€™t updated repo in a while.

Openclaw doctor ā€”fix doesnā€™t work on this

And openclaw config set too

So have to edit config file nano doesnā€™t work too so need a command from you to edit config then i will openclaw uodate and after that i need idea that how can we fix this issue forever

sudden wedgeBOT
#

Yep, that tracks.

Whatā€™s happening is:

  • Railway keeps /data
  • your newer config survives in /data/.openclaw/openclaw.json
  • but redeploy pulls the old 2026.3.13 app code from that stale template
  • old code canā€™t read the newer channels.discord.streaming shape, so boot dies again

So this is basically version drift between code and persistent config.

Use this in the Railway shell to patch the config directly, without nano:

node -e 'const fs=require("fs"); const p="/data/.openclaw/openclaw.json"; const cfg=JSON.parse(fs.readFileSync(p,"utf8")); fs.copyFileSync(p,p+".bak"); cfg.channels ??= {}; cfg.channels.discord ??= {}; cfg.channels.discord.streaming = "partial"; fs.writeFileSync(p, JSON.stringify(cfg, null, 2) + "\n"); console.log("updated:", p, "backup:", p + ".bak");'
#

Then run:

openclaw --version
openclaw update
openclaw doctor
openclaw gateway restart

Forever fix

openclaw update will unblock you for now, but it will not fix the root cause if Railway keeps redeploying from an old template.

The real fix is:

  1. Stop using that stale Railway template
  2. Repoint/recreate the service from the current official Railway setup:
#

https://docs.openclaw.ai/install/railway
3. Make sure the deploy source itself is current, otherwise every redeploy will rewind the code again

So, short version: persisted /data + old template redeploy = same config crash forever.

If you paste the Railway repo/template link or the build/start command, I can tell you the cleanest permanent setup.

silver hazel
#

Ok docs shows a template too so in same service i deploy this template and in service settings i change source ?

sudden wedgeBOT
#

Yes, if Railway lets you change the existing serviceā€™s source cleanly, thatā€™s the simplest path.

Iā€™d do it like this:

  1. Back up first if you can

    openclaw backup create

  2. Point that same service to the official/current OpenClaw Railway template/repo

  3. Keep the same env vars

  4. Keep the same /data volume attached

  5. Redeploy

  6. Check:

    openclaw --version
#

That should stop the old 2026.3.13 code from coming back on redeploy.

If Railway doesnā€™t let you switch the source nicely, then do this instead:

  • create a new service from the official template
  • attach the same /data volume, or restore from backup
  • copy over the same Railway variables

My recommendation: use the official template, not the old third-party one.

Docs:

If you want, send a screenshot of the Railway service settings page and Iā€™ll tell you which button to press.

silver hazel
#

Where will it save backup after Openclaw backup create and how will i load it back

sudden wedgeBOT
#

By default, openclaw backup create writes the archive to the current working directory.

On Railway, I would not rely on that, because you usually want the backup on the persistent volume. Use /data/backups explicitly:

mkdir -p /data/backups
openclaw backup create --no-include-workspace --output /data/backups --verify

or, if you only want the config file:

openclaw backup create --only-config --output /data/backups --verify

A couple important bits:

#
  • Right now your config is invalid, so plain openclaw backup create can fail
  • In that situation, use:
    • --no-include-workspace, or
    • --only-config

Where the file ends up

Something like:

/data/backups/2026-04-16T18-36-00.000Z-openclaw-backup.tar.gz

The command also prints the exact path after it creates it.

How to restore it

#

There is verify, but not a first-class openclaw backup restore command yet.

So restore is basically:

  1. extract the archive
  2. inspect manifest.json
  3. copy the files back into place

Example:

mkdir -p /tmp/openclaw-restore
tar -xzf /data/backups/<your-backup-file>.tar.gz -C /tmp/openclaw-restore
find /tmp/openclaw-restore -name manifest.json -print

On Railway, the main places youā€™d usually restore back to are:

#
  • /data/.openclaw
  • /data/workspace

For your current issue

Honestly, for this one, the simplest backup is just the config file itself:

mkdir -p /data/backups
cp /data/.openclaw/openclaw.json /data/backups/openclaw.json.$(date +%F-%H%M%S).bak

Thatā€™s the easiest ā€œundoā€ button before editing.

If you want, I can give you the exact backup + patch + restore command sequence for Railway.