Note that, there's nothing wrong. The deploy works fine without any errors or warnings and the app works fine. It's just…. slow to get there. Hurts the dev cycle a bit.

hello, would you mind if i shared the build table here so we can talk about it, I'm seeing a lot of room for improvements

which is the build table?

the table at the top of the build logs

oh at the top of the build?

sure

i see a couple spots where the build takes many seconds, esp at the end. but also the deploy step after build takes about 2 mins

is that just because the codebase has gotten to be sprawling? (node_modules is huge now?)

1. i dont think your svelte app needs libreoffice and all of its deps?

2. you are enabling corepack twice, once in the install, and again in the build phase

3. your install command is installing all deps for all packages, you can likely get away with only installing the deps needed for the svelte app.

4. you are running install twice, once during the install phase, and again in the build phase.

5. its a tell tale sign if you are using cd in any phase, something is being done wrong, you should be using the --filter flag for pnpm instead

im sure theres more, but thats what sticks out to me

THANK YOU!

1. my svelte app doesnt need libreoffice, but my backend does. it's a monorepo. i'll think about how i can improve this so it's not installed in the frontend's container

2. which stage should i be using to enable corepack, install or build?

3. monorepo-- not sure if can just install minimums for svelte app, but will play around here

4. good catch!

5. blame AI 🙂

I'll look at all these suggestions.

But would you say all this affects the deploy time after the build as well? (maybe because libre is huge? idk)

maybe netlify is doing cache on your builds while Railway doesn't most of the times

1. do you have a nixpacks.toml file with those deps defined? you could create a svelte specific nixpacks.toml file that doesnt include that stuff.

2. yep, install only.

3. maybe, im not sure if your svelte app will rely on built files from other packages.

4. 🙂

5. fair

But would you say all this affects the deploy time after the build as well? (maybe because libre is huge? idk)

oh yes for sure, a lot is happening that doesnt need to, you could likely even get your build times down even further with a custom dockerfile since then you could really tweak every bit of how the build is done.

we somewhat fixed this 🙂

still not perfect though, cache is per builder instead of being central, and builders cycle, you can land on a different builer, etc

there's no silver bullet here, i think is your takeaway @brody

i've clearly just got to bear down and redo everything with my own docker, feels like, vs battling with nixpacks. then i can test it faster locally to ensure that the docker build phases are quick. agree?

like, a container config for each of my services in the monorepo.

you could definitely do all you need to with a nixpacks.toml file, but I personally would do with a Dockerfile, yeah

a dockerfile for each package

and dont use cd lol

right, no more cd FTW

do you guys have any example projects i could reference on how to set up the dockerfile within railway?

Just have a svelte.Dockerfile in your repo and set a RAILWAY_DOCKERFILE_PATH=svelte.Dockerfile variable

!s