feat(railway): build staging target with pre-bundled WASM extensions - #2219
Conversation
Add railway.toml with target = "runtime-staging" so Railway builds the Docker target that includes all WASM tool/channel extensions. All Railway environments deploy from the staging branch and benefit from having extensions pre-installed. Depends on the runtime-staging Dockerfile target added in #2210. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
github-actions
Bot
added
size: S
There was a problem hiding this comment.
Pull request overview
Adds a Railway configuration to ensure staging deployments build the Docker image stage that includes pre-bundled WASM tool/channel extensions, aligning Railway’s build behavior with the existing runtime-staging Docker target.
Changes:
- Add
railway.tomlto configure Railway Docker builds to usetarget = "runtime-staging". - Configure Railway deploy healthcheck settings for
/api/healthand restart-on-failure behavior.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces a railway.toml configuration file to define build and deployment settings for the service. The review suggests reducing the healthcheckTimeout from 300 seconds to 60 seconds to avoid masking potential application unresponsiveness, as the health endpoint is expected to be fast.
|
|
||
| [deploy] | ||
| healthcheckPath = "/api/health" | ||
| healthcheckTimeout = 300 |
There was a problem hiding this comment.
A health check timeout of 300 seconds (5 minutes) is excessively long, especially since the /api/health endpoint returns a static response and should be very fast. While a longer timeout can be useful if the service has a slow startup time, 5 minutes can mask issues where the application becomes unresponsive. Consider reducing this to a more reasonable value, for example 60 seconds. If the application startup is indeed very long, it might be worth investigating if Railway offers an initial delay for health checks to handle this more gracefully.
| healthcheckTimeout = 300 | |
| healthcheckTimeout = 60 |
…earai#2219) Add railway.toml with target = "runtime-staging" so Railway builds the Docker target that includes all WASM tool/channel extensions. All Railway environments deploy from the staging branch and benefit from having extensions pre-installed. Depends on the runtime-staging Dockerfile target added in nearai#2210. Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Summary
railway.tomlwithtarget = "runtime-staging"so Railway builds the Docker target that includes all pre-built WASM tool/channel extensionsruntime-stagingDockerfile target added in feat(docker): pre-bundle WASM extensions in staging image #2210Without this, Railway runs a bare
docker build .which builds the last stage (runtime— no extensions). Withtarget = "runtime-staging", Railway builds the staging target that includes.wasmfiles in~/.ironclaw/{tools,channels}/.Test plan
=== Building ... ===lines from the wasm-builder stageironclaw-production-near-ai.up.railway.appis healthy via/api/health🤖 Generated with Claude Code