7 months ago
Here's an excerpt from the build log. Note that the executable is supposed to be out, same as the default.
2026-02-01T16:06:24.864010066Z [inf] copy go.mod
2026-02-01T16:06:24.864010226Z [inf] copy go.sum
2026-02-01T16:06:24.864010497Z [inf] go mod download
2026-02-01T16:06:28.734245274Z [inf] go mod download
2026-02-01T16:06:28.855672236Z [inf] copy / /app
2026-02-01T16:06:29.576028287Z [inf] copy / /app
2026-02-01T16:06:29.644497562Z [inf] go build -ldflags='-w -s' -o ./out ./
2026-02-01T16:06:31.618543445Z [inf] go build -ldflags='-w -s' -o ./out ./
2026-02-01T16:06:32.677379076Z [inf] copy /app
2026-02-01T16:06:32.677536282Z [inf] install apt packages: tzdata
2026-02-01T16:06:33.029944994Z [inf] copy /app
2026-02-01T16:06:33.174591766Z [inf] [railpack] merge $packages:apt:runtime, $build
2026-02-01T16:06:33.449283199Z [inf] [railpack] merge $packages:apt:runtime, $build
2026-02-01T16:06:33.513383835Z [inf] exporting to docker image format
2026-02-01T16:06:34.341504587Z [inf] exporting to docker image formatHowever, here are the actual files. Note that the executable is named as callbridge, used to be the project name.
```
root@cba967088c87:/app# ls -lart
total 17920
-rw-rw-r-- 1 root root 449 Feb 1 16:05 railway.json
-rw-rw-r-- 1 root root 208 Feb 1 16:05 railpack.json
-rw-rw-r-- 1 root root 1147 Feb 1 16:05 main.go
-rw-rw-r-- 1 root root 25275 Feb 1 16:05 go.sum
-rw-rw-r-- 1 root root 3676 Feb 1 16:05 go.mod
...
drwxr-xr-x 1 root root 4096 Feb 1 16:06 ..
-rwxr-xr-x 1 root root 18262811 Feb 1 16:06 callbridge
drwxr-xr-x 1 root root 4096 Feb 1 16:06 .
```
This looks like a bug. I had to put sleep 10000 as startCommand to be able to SSH into the container to figure this out.
Also note that some log entries are shown twice but with different timestamps. Not sure if the build process actually ran twice, or it's just a log processing issue.
Another side note - why the second code block wasn't rendered? I really tried hard when editing but no luck.
1 Replies
15 days ago
The build log shows that Railpack did create /app/out successfully. The runtime listing showing an older callbridge binary therefore points to /app being replaced at container start, not to Go choosing a different output name.
First check the service's attached volume and the value of this Railway-provided variable from the runtime shell:
printf '%s\n' "$RAILWAY_VOLUME_MOUNT_PATH"If it prints /app, that is the cause. Railway builds the application into /app, while volumes are mounted only when the container starts. A volume mounted at /app hides the files packaged in the new image and exposes the older files stored on the volume instead. That exactly explains why the build log contains -o ./out but SSH sees the previous callbridge executable.
Move the volume mount to only the directory that actually needs persistence, for example /app/data (or /data), update the application to write there, and redeploy. Do not wipe the volume just to test this; moving the mount preserves the data while avoiding the application directory.
The relevant documentation confirms all three pieces:
- Railpack's Go provider names the output binary
out: https://railpack.com/languages/golang/#configuration - Railway puts application files in
/appand recommends/app/datafor relative persistent data: https://docs.railway.com/volumes#relative-paths - Volumes are mounted at runtime, not during the build: https://docs.railway.com/volumes#volume-availability
After redeploying, verify with:
printf 'mount=%s\n' "$RAILWAY_VOLUME_MOUNT_PATH"
ls -la /app/outIf no volume is attached or the mount path is not /app, then this explanation is ruled out; in that case, post the service's Start Command and the contents of railpack.json/railway.json (with secrets removed), because the shown build and runtime files otherwise come from different filesystem layers or deployment images.
The duplicated log lines are separate from the filename problem and do not prove that Go compiled two different binaries.