Railpack installs all your Python packages into its own virtual-env at /app/venv. When the container boots it doesn’t add that venv’s “bin” folder to the default PATH, so a bare uvicorn call can’t be found even though the package is there.

Fix is simple actually:

1. Open railway.json.

2. Swap the startCommand for one of these lines:

   • /app/venv/bin/uvicorn model_server.main:app

   • or python -m uvicorn model_server.main:app (this also works because it asks Python to run the module directly).

3. Commit and push and it'll rebuild the image and, this time, the backend starts because it’s pointing at the exact location of the Uvicorn binary.

You don’t need to build anything locally. Just that one path tweak, redeploy, and get some rest lol.

Faced something similar before with Nixpacks + pip. Uvicorn was installed, but wasn’t available when the app started because it wasn’t in the system path.

What fixed it for me:

1. During the install phase, I made sure to install uvicorn explicitly using pip.

2. In the start command, I used:

uvicorn your_module:app --host 0.0.0.0 --port ${PORT:-8000}

Or, to avoid depending on the system path, this also works:

python -m uvicorn your_module:app --host 0.0.0.0 --port ${PORT:-8000}

That last one is more reliable if you’re running in a virtualenv or if pip doesn’t expose uvicorn globally.

Didn’t need to touch Docker or rebuild anything. Just added that and it worked.

Do you have an example repo that can be used to test? Everything installed with pip should be available on the global path.

The default install command for Python will add /app/.venv to the global path which will make all pip installed packages available.

    {
      "name": "install",
      "inputs": [
        {
          "step": "packages:mise"
        }
      ],
      "commands": [
        {
          "cmd": "python -m venv /app/.venv"
        },
        {
          "path": "/app/.venv/bin"
        },
        {
          "src": "requirements.txt",
          "dest": "requirements.txt"
        },
        {
          "cmd": "pip install -r requirements.txt"
        }
      ],

I've looked at your setup, an I think I have a solution that might work (although I'm not able to test on any real code). The key here is specifying the "provider" in the railpack.json file. You could then also specify other commands (like bun install) in the install step too.

I'm trying to understand your usecase a bit better though. Why are you trying to install everything custom instead of having Railpack detect the config automatically?

{
  "$schema": "https://schema.railpack.com",
  "packages": {
    "bun": "latest",
    "node": "latest"
  },
  "provider": "python",
  "steps": {
    "install": {
      "commands": [
        "...",
        "python -m venv /app/.venv",
        { "path": "/app/.venv/bin" },
        { "src": ".", "dest": "." },

        // Specific to your app
        "pip install -e ./server/model-server"
      ],
      "caches": ["pip"],
      "deployOutputs": []
    }
  },
  "caches": {
    "pip": {
      "directory": "/opt/pip-cache",
      "type": "shared"
    }
  },
  "deploy": {
    "inputs": [
      {
        "step": "packages:mise",
        "include": [
          "/mise/shims",
          "/mise/installs",
          "/usr/local/bin/mise",
          "/etc/mise/config.toml",
          "/root/.local/state/mise"
        ]
      },
      {
        "step": "build",
        "include": ["."]
      }
    ]
  }
}

python -m uvicorn model_server.main:app

This was the second thing I tried actually! I'd have to wade through a several dozen test commits to find the exact incantation so we could try to find the discrepancy, but unfortunately neither uvicorn nor the other packages I installed were showing up in the found modules.

Unfortunately the auto-detected configuration wasn't working at all for me. This is probably due to some misunderstanding on my part, but documentation was sparse. I managed to get things working (albeit briefly) with a slightly different configuration that manually created the venv, copied it over, and ran python from the venv -- but for reasons I still don't understand that stopped working remotely when building on railway (see the other thread I created, fails with code 137: https://station.railway.com/questions/local-railpack-build-succeeds-but-remote-1801c2f0). I eventually resorted to building an image with railpack locally, uploading it to ghci, and then using the docker image to deploy onto railway -- which seems to work fine but I was hoping to avoid.

This is the final railpack config which works perfectly locally:

I can live with this in the short term, but I'm still very interested in figuring out the root cause and letting railway handle the whole process automatically.

I'm not sure what the bug tracking etiquette is here -- should I close this issue and attempt to resolve in the other thread? Or would it be better to close that thread and consolidate here?

Apologies, I'm having a heck of a time actually getting replies posted due to the frequent 403 errors. Every time I attempt to edit my comment to include the config it seems to fail, so here's a gist link: https://gist.github.com/joshuafcole/d95f2d50a749ef38278c2697e441b96f

Following up, I attempted to set the provider (and added back in caching because it evidently wasn't the cause of the problem), and get the same code 137 abort, now during the apt install stage that got added.

Config: https://gist.github.com/joshuafcole/d4e32b928eecf11c45592efeee7bef7a

Logs: https://gist.github.com/joshuafcole/a3a9b7d321b8f5e5890db59d1f85eda5

It still works when built locally and I run the image.

This is useful to debug, thanks. One thing I immediately notice is that you are not updating the path after creating the venv, which is why you need to manually specify the path to uvicorn in the start command. That is not a big deal though.

More importantly, the error when building on Railway vs local.

This error, "/client/apps/modeler/dist": not found indicates that Railpack is trying to construct an image but failing to copy over that folder. Why it is trying to do that, I am not sure. It is likely building okay locally because that directory exists locally but does not exist when Railway is building (because of gitignore).

I'm not sure what the bug tracking etiquette is here

We can use either thread. I think the original problem of uvicorn not being found is solved? But it is useful to have all the context in a single place.

Do you have a link to the deployment on Railway that is failing. I'd like to see the full build plan there. It does seem like Railpack is incorrectly trying to copy files into the build context.

Additionally (and completely optional), you could create an issue in the Railpack repo, https://github.com/railwayapp/railpack/issues, with a link to a minimal GitHub repo where this problem occurs.

Hey JR, really appreciate the help and apologies for the slow response time. We have a demo coming up shortly that we've been heads down on. Thanks to your earlier messages and the improved understanding of railpack they gave me, I was able to eventually land on a successful config, see attached. It could likely still be improved further, but it'll tide us over for the demo. After the demo ends, I'd like to come back with an MRE and see if we can work together to figure out what went wrong in the zeroconf flow -- if you prefer I can file a separate issue against railpack for that.

One other minor request for other folks adopting railway is to provide a clearer guide on the interplay between railpack and railway (esp. when some manual configuration is needed). In retrospect it's a lot clearer now what was going on, but not having prior experience with buildkit or an understanding of the difference between the emitted plan syntax and the railpack config itself led to a few frustrating hours of trying random permutations to railway to respect my attempts to configure railway. The two biggest doc wins there that would save past-me some time would be:

• clarify the difference between who uses railpack.json, railpack-plan.json, and railway.json and for what

• clarify the difference between the railpack configuration schema and the emitted railpack-plan schema -- I was using buildkit directly and hand-editing the plan (based on what it initially emitted for me) without realizing I was skipping a step.

Another deeper cut that would be excellent would be a sample repo that uses railpack and railway with manual configuration. If I'd started from a template like that I think I would have just stumbled into the happy path.

One outstanding question is why exactly we were hitting that code 137. I was originally writing off the failue to copy dist based on the fact that I was getting the error code 137 much earlier in the process, while trying to run the bun install. Building the frontend was sequenced after that, so of course it wouldn't be there if the frontend install had failed. It's not clear to me why railpack would have continued running after the install failure though, which has me wondering if perhaps I'm missing something about how railpack chooses to sequence tasks.