Having looked into this, the issue appears to be in your application code or configuration rather than the Railway platform itself, which puts it outside what Railway support can resolve directly.

This is exactly the kind of problem the Railway community is good at, so we'd like to open your thread as a community bounty. Railway pays a bounty to the community member who solves it, and threads like this usually get picked up quickly.

Opening it makes this entire thread public, including everything already posted. Nothing becomes public until you decide. Use the buttons below.

• Open to the community - Before you click, take a moment to edit or remove anything you'd rather not share. The thread becomes publicly visible right away.
• Keep it private and close the thread - Nothing becomes public and the thread closes.

but this is completely related to the packages and how they are getting installed

This still looks like an application-level problem, so Railway support can't take it further, but the community can. The buttons below are still live: open the thread up as a public bounty after editing out anything sensitive, or keep it private and close it.

It was working completely fine with the same dockerfile a few days ago

Nothing changed

Kindly check into the build time for Railway, there was no change made into the dockerfile or the way the image is getting built

This still looks like an application-level problem, so Railway support can't take it further, but the community can. The buttons below are still live: open the thread up as a public bounty after editing out anything sensitive, or keep it private and close it.

It does seem like builds are taking a really long time, I just need to quickly build this playwright mcp docker image and it takes like 3 minutes to actually start building. The first 2 and a half minutes are just blank

here's the Dockerfile

FROM mcr.microsoft.com/playwright/mcp:latest

COPY <<'EOF' /config.json

{

  "imageResponses": "allow",

  "browser": {

    "contextOptions": {

      "userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/151.0.0.0 Safari/537.36",

      "locale": "en-US",

      "timezoneId": "America/New_York",

      "viewport": { "width": 1440, "height": 900 },

      "deviceScaleFactor": 2,

      "colorScheme": "light",

      "extraHTTPHeaders": {

        "Accept-Language": "en-US,en;q=0.9"

      }

    },

    "launchOptions": {

      "args": ["--disable-blink-features=AutomationControlled"]

    }

  }

}

EOF

ENV PLAYWRIGHT_MCP_CONFIG=/config.json

My other projects used to only takes around 40s - 1m to build and deploy, now it takes a good 5 minutes with 3 minutes just waiting, when the build and deploy comes, it only takes a short time since everything is cached

Can you share your Dockerfile?

I don't think your issue is related to the issue OP is currently having.

Maybe just a busy builder.

so I just did redeploy on some of my service and I do seem to realize that about exactly 3 - 3m10s do the building and deploying starts, it could be the servers are busy I get it, but usually my deploys are about 40s so that's why I give comment on this, not exactly OP's fault so my comment might be a bit out of place

I'm experiencing super slow builds too - something that usually takes < 2 minutes is taking close to 10 at the moment

Your build error and the "packaging" pip-uninstall failure are the same root cause, not two separate problems.

What's happening: Skipping virtualenv creation, as specified in config file means Poetry is installing packages directly into the base image's shared system site-packages instead of an isolated virtualenv. Combined with Railway/Nixpacks caching build layers between deploys, old compiled files from a previous build can persist alongside newly-resolved package versions. Your log shows the lockfile resolving 55 installs/updates — that fresh resolution collided with stale cached files from the prior build, which is exactly what produces AttributeError: module 'charset_normalizer.md' has no attribute 'CharInfo' (the compiled cd extension and the pure-Python md module are from two different versions of the package sitting on disk at once). The pip uninstall packaging CalledProcessError right after is a downstream symptom of that same inconsistent environment — a partial version mismatch often corrupts pip's install metadata enough that clean uninstalls fail.

That's also why "nothing changed in the Dockerfile" — you're right, it didn't need to. The lockfile resolving differently against a stale cached layer is enough to trigger this on its own.

To unblock immediately:

1. Clear Railway's build cache for this service (Settings → and redeploy — this forces a completely clean base layer instead of reusing the corrupted cached one).

To fix it properly so it doesn't recur:

1. Stop skipping virtualenv creation. If you have POETRY_VIRTUALENVS_CREATE=false set as an env var, or create = false under [virtualenvs] in your Poetry config, remove it. Installing into an isolated venv means a stale system-level package can never collide with what Poetry resolves fresh each build.
2. Pin charset-normalizer to an exact version in pyproject.toml (e.g. charset-normalizer = "3.4.0") and regenerate poetry.lock, so a future lockfile resolution can't silently pull in an incompatible version.

If clearing the cache alone fixes it, that confirms the stale-layer theory. If it still fails after a clean cache, the next thing worth checking is whether your base/builder image itself already ships a system-level charset-normalizer that's colliding with Poetry's install — happy to help dig into that if step 1 doesn't fully resolve it.