Build time timeout?
jegnux
PROOP

2 years ago

I'm currently on the free trial plan and when I build my Swift Vapor project in release mode, it fails at 10 minutes. In debug mode it builds faster (~ 4 min) so it works fine. But as I move close to releasing in production I'd like to make sure it will build just fine. Is there an official build timeout? Will I get a higher timeout if I move to the Hobby or the Pro plan?

26 Replies

jegnux
PROOP

2 years ago

514d89a5-dd8e-4c00-87ad-520e173a207f


2 years ago

the Hobby plan has a longer build timeout than the trial plan, and the pro plan has a longer build timeout than the Hobby plan.

but you should not be concerned with the build timeout, you would want to figure out why building your app for production is taking 10 minutes, I'm assuming that is not normal for a swift vapor app?


jegnux
PROOP

2 years ago

Swift is pretty known to have slow compile times, especially in release mode where it optimizes a lot of stuff (for better runtime performances). As a reference, on my Macbook Pro M3 Max (48Go ram), the command swift build -c release --static-swift-stdlib takes 58s to complete, while swift build -c release --static-swift-stdlib takes 165s (so ~ 2.85x). The whole build in debug on railway takes ~ 4min, so I guess in release it takes ~ 11-12min ?


2 years ago

well you get 20 minute build times on Hobby so that should be good?


jegnux
PROOP

2 years ago

yes it should be (hope so)


jegnux
PROOP

2 years ago

I planned to take the pro plan, to have EU servers


2 years ago

pro plan has even longer allowable build times, though I don't remember it off the top of my head


jegnux
PROOP

2 years ago

if I deploy from cli, does it build the docker image on my machine and deploy it to railway, or the build is still done on railway?


2 years ago

still done on Railway


2 years ago

though you can deploy to any one of our supported registries -

keep in mind you will need to build an x64 image, we don't support ARM


jegnux
PROOP

2 years ago

I'm quite novice at backend stuff (I'm a iOS developer) so I'm not really familiar with all that Docker can offer, I'll try to take a look to registries but I have to admit that the kind of "plug and play" side of railway is what interested me the most 😄


2 years ago

well railway doesn't charge for builds at the moment so if you are cool with waiting then railway up away!


2 years ago

or GitHub, whatever you prefer


jegnux
PROOP

2 years ago

does "at the moment" mean "but anytime soon"? 😅


2 years ago

we don't currently have any plans to charge for build


jegnux
PROOP

2 years ago

ok thanks


jegnux
PROOP

2 years ago

Side question : if I want to build 2 vapor apps defined in separate Dockerfile.server and Dockerfile.client files in the same directory, I have to pass the dockefile path as environment right?


2 years ago

correct, did you need the name of that variable?


jegnux
PROOP

2 years ago

No I already found it a while ago, I'll be able to find it again ^^


2 years ago

sounds good


jegnux
PROOP

2 years ago

Can I have 2 services that shares the same build but have different run commands ? I wonder if I can build my vapor app only once, but run it as the client or as the server 🤔


2 years ago

each service has separate build context so not natively, you would need to build and publish an image (GitHub action and ghcr) and then have Railway run that image while overwriting the entrypoint of the image (start command in service settings?


2 years ago

or you could get really funky, single service but start two processes within the same container using parallel


jegnux
PROOP

2 years ago

interesting. But if one of the processes crash, what happens ? both terminates and railway start them both again right? I would need to handle independant process restart myself?


2 years ago

GNU parallel handles that for you, when correctly configured it will do just that!


2 years ago

the false is there to make sure the container exits with an error code, in case one of those two commands exits with a non error code for some reason, parallel will exit with its child's exit code, there's no scenario where those should ever exit so if they do, it will always count as a container crash so Railway can restart.

keep in mind, this option only works if both your client and server are http servers, because then you can use target ports to expose them both publicly -


Welcome!

Sign in to your Railway account to join the conversation.

Loading...